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ABSTRACT 


A SYNTAX-ORIENTED ARTIFICIAL LANGUAGE TRANSLATOR 
by Laetitia Harrer Snow 


ADVISOR: Professor William E. Ball 


June, 1967 

Saint Louis, Missouri 


This paper will present a general description of syntax- 
oriented artificial language translation. Special reference 
will be made to the techniques developed by Ingerman, and an 
implementation of these techniques in PL/I. 

Section 2 of this paper presents some of the methods used 
in describing syntax, semantics, and pragmatics, together with 
problems encountered both in the language specification, and in 
the techniques to make use of the specification. The syntax- 
controlled approach (in which the syntax is not explicitly 
stated) and some of the advantages and disadvantages of the 
syntax-oriented techniques are discussed. 

Section 3 presents the techniques for syntax-oriented 
translation developed by Ingerman. The metasyntactic language, 
and the rationale behind it are discussed, along with a 
description of the notion of an acceptability table for deciding 
the applicability of a rule. The metasemantic language and 
pragmatics are presented. A brief discussion of the parsing 
and unparsing processors, and of the PL/I program which has 
been written to implement the process are included. 
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A SYNTAX-ORIENTED ARTIFICIAL LANGUAGE TRANSLATOR 


1. INTRODUCTION 


This paper will present a general description of 
syntax-oriented artificial language translation. Specific 
reference will be made to the techniques developed by 
Ingerman (1)*, and an implementation of these techniques in 
PL/1. 

A translator is a processor which accepts input written 
in a given source language and produces output written in a 
different target language. In order for such a processor to 
function, it must have available to it descriptions of the 
structure of the source language, and of the relationship 
between the source language and the target language. 

A description of the structure of a language is generally 
known as the syntax of a language. The syntax is used to 
distinguish whether or not a given subset of the source 
language input string is "grammatically’' correct. If so, a 
representation of the structure of the input string can then 
be constructed. 

* The numbers in parentheses indicate references in the 
Bibliography. 
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A description of the relationship between the source 
language and the target language must include two parts: {a) 
the set of possible meanings (in terms of the target language) 
attributable to each of the syntactic elements; and (b) a 
statement of exactly which meaning is to be used for each 
element at a given time during the translation process. The 
first of these will be referred to as the semantics of the 
source language in terms of the target language. The second 
will be referred to as the pragmatics of the source language 
in terms of the target language. 

A syntax-oriented translator is one in which the trans¬ 
lation of the source language to the target language is 
accomplished by using an explicit statement of both the syntax 
of the source language and the semantics and pragmatics of the 
source language in terms of the target language. This is in 
contrast to other methods of translation which have the structure 
of the source language, and its meaning in terms of the target 
language, implicitly "buried" in the coding of the translator. 

Section 2 of this paper presents some of the methods used 
in describing syntax, semantics, and pragmatics, together with 
problems encountered both in the language specification, and 
in the techniques to make use of the specification. The 
syntax-controlled approach (in which the syntax is not explicitly 
stated) and some of the advantages and disadvantages of the 
syntax-oriented techniques are discussed. 
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Section 3 presents the techniques for syntax-oriented 
translation developed by Ingerman (1). The metasyntactic 
language, and the rationale behind it are discussed, along 
with a description of the notion of an acceptability table 
for deciding the applicability of a rule. The metasemantic 
language and pragmatics are presented. A brief discussion 
of the parsing and unparsing processors, and of the PL/I 
program which has been written to implement the process are 
included. 


. 







2. METHODS OF TRANSLATION 


2.1 INTRODUCTION 

Despite wide variations in approach, all translation 
methods have two basic components in common. These are: (a) 
a description of the syntax, semantics, and pragmatics of 
the source-target language pair; and (b) a processor which 
translates an input string using this description. 

In practice, translating techniques may be divided into 
two main categories, syntax-oriented, and what has been called 
syntax-controlled (2). The terms syntax-oriented and syntax- 
controlled are not really definitive terms; more appropriate 
might be explicit syntax and implicit syntax respectively. 
However, because they are more widely known, the former terms 
will be used here. 

The basic difference in these two categories lies in the 
relationship between components (a) and (b) above. In syntax- 
oriented methods, the processor is separate from, and is 
literally directed by, the formal description of the source- 
target language pair. In syntax-controlled methods, the 
description is coded and becomes an integral part of the 
processor, so that the two components are inseparable. 









2.2 SYNTAX-ORIENTED TRANSLATORS 


2.2.1 Definitions and notation 

A metalanguage is a language used to describe another 
language. In particular, a metalanguage whose specific 
purpose is to describe the syntax of a language is known as 
a metasyntactic language (or possibly a syntactic metalanguage) . 
Metasemantic languages are defined similarly. A number of 
metalanguages for description of syntax and semantics have 
been proposed. For some examples, see references (3) through 
(9) . The most well known of these is Backus Normal Form, a 
metasyntactic language used to define Algol 60 (3) . 

The most basic elements in a metasyntactic language are 
the allowable source language characters, called base objects 
(or terminal types ) . In this paper they are written as 
characters delimited by single quotes (as 'A')- Defined 
types (abbreviated as d-type) are syntactic elements which 
are defined in terms of other defined types or base objects. 
Defined types (or names) are represented by one or more lower 
case letters; in the case of a multiword name, the words are 
strung together with hyphens. Syntactic types (abbreviated 
as s-type) are either defined types or terminal types. The 
head of the language is that syntactic element which designates 


the "largest" construction possible in the language. 
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The structure of a language can be represented as a tree 
structure, known as a syntax tree . The head of the language 
is at the top of the tree, and the base objects are at the 
bottom. Between the head of the language and the base objects 
are all the defined types of the language. Parsing is the 
process of breaking up a source language input string into 
all its constituent defined types according to the syntax of 
the language. Parsing is analogous to tracing out a path 
through the syntax tree. 

2.2.2 A Prototype Metasyntactic Language 

A metasyntactic description of a source language is 
composed of a set of metasyntactic statements. These state¬ 
ments are used to define all the syntactic elements of the 
language. A skeletal form for such statements which illus¬ 
trates the essential constituents is 

defined type = a sequence of syntactic types [1] 

The equal sign serves to separate the defined type on the 
left from its definition on the right. 

In order to represent adequately the relationships which 
exist between various syntactic elements in a definition, it 
is necessary to introduce the two operators '+ ' {for concate¬ 
nation) and ’/' (for alternation). Concatenation denotes the 
positional relationship between two syntactic elements, as in 
'A' + 'B', This is read as "the character A followed by the 
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character B". Alternation denotes alternative definitions 
for the same syntactic type, as in ' A*/ 'B 1 , which is read as 
"the character A or the character B". 

It is now possible to develop statement [1] more fully. 

It can be rewritten as 

d-type = s-typey s-type 2 / ... / s-type n 

or [2] 

^“type “ s-typej + s-type 2 + ... + s-type^ 

or a combination of these. This gives more flexibility in 
stating syntax; for example, the following could be written; 

letter = 'A'/'B'/.../'Z' 

four-letter-word - letter + letter + letter + letter. 
Parentheses are used to indicate logical grouping of 
syntactic elements, in order to indicate precedence of analysis. 
One possible form in which the statements [2] might be combined 
is 

d-type = {s-type : + s-type 2 >/s-type, [3] 

This statement indicates that 'd-type' has two alternative 
definitions, either ’s-type^ followed by 's”type 2 *, or 's-type 3 '. 
As an example, a definition of identifier can be written as 
identifier = letter / (identifier + letter) . 

This states that 'identifier' will be either 'letter', or 
'identifier' followed by 'letter*. 
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The above example is an illustration of the important 
concept of recursive definitions. The purpose in this case 
is to define 'identifier' as a string composed of one or 
more elements ’letter'. Unless recursive definitions are 
allowed in the metalanguage as described so far, there is 
no way to make this definition without limiting the number 
of elements allowed. For example, the statement 
identifier - letter/(letter + letter}/ 

(letter + letter + letter) 

limits the number of elements 'letter' to three. Thus re- 
cursion is a compact means of representing the concept of 
an arbitrary number of elements. 

It should be noted that in a recursive definition the 
number of elements can not be limited. A method for includ¬ 
ing the basic purpose of recursion, while making it possible 
to limit the number of elements, is to define a new operator 

This operator means essentially "one or more occurrences 
of The definition of 'identifier' can now be written as 

identifier - $ letter 

This method is used in the Meta II language (4} (the specifi¬ 
cations for which are listed in Appendix 6.1). An extension 
is to precede the operator by a number which is an upper 

bound on the number of elements. For example, to limit 
'identifier' to a maximum of six elements ’letter*, the 
definition is 

identifier = 6 $ letter 







A language is called a simple phrase structure language 
if it satisfies three basic requirements (9). (Equivalent 
names that are used are "type-2 language" and "context free 
grammar" (10).) First, if a defined type appears on the 
right hand side of a statement such as [3], then it must also 
appear on the left hand side of such a statement. That is, 
if a defined type is used, it must be defined. 

Second, it must be possible to reduce every defined 
type ultimately to a set of terminal types. This requirement 
will be more obvious if the notion of the syntax tree is 
remembered. There must be a path from each defined type to 
the terminal types at the bottom of the tree. 

Third, there must be a "largest" defined type. That is, 
there must be at least one defined type which does not appear 
on the right hand side of any statement of the form of [3] 
above, except possibly the one which defined it. This defined 
type is the head of the language. 

Table 1 gives the syntax specification of a simple 
language of assignment statements. The syntax is described 
using the metasyntactic language developed. 

2.2.3 Semantic Specification 

The metasyntactic language developed in the previous 
section illustrates the construction of syntax statements. 
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TABLE 1 

Rules For a Simple Assignment Statement Language 

The rules given here specify a simple language consisting 
of assignment statements. The rules allow identifiers 
consisting only of letters, and only integer constants. 

1. assignment-statement = left-part + arithmetic-express ion 

2. left-part = identifier + equal-sign 

3. arithmetic-expression - (arithmetic-expression + 

unary-arithmetic-expression)/ 
unary-arithmetic-expression/term 

4. unary-arithmetic-expression = adding-operator + term 

5. term = (term + multiplying-operator + factor)/factor 

6. factor - (factor + exponentiation-sign + primary)/primary 

7. primary = (left-parenthesis + arithmetic-expression 

+ right-parenthesis)/identifier/ 
unsigned-integer 

8. identifier = (identifier + letter)/letter 

9. unsigned-integer = (unsigned-integer + digit)/digit 

10. adding-operator = 1 + '/***' 

11. multiplying-operator = 

12. letter = 'A 1 /.. ./’Z' 

13. digit = '0'/.. ./'S' 

14. equal-sign - '=' 

15. exponentiation-sign = 1 +' 

16. left-parenthesis = '(' 

17. right-parenthesis = ')' 







These statements are used to recognize occurrences of the 
various defined types in the source language input string. 
Associated with each syntactic element there is a set of 
semantic elements which specify the meaning of the source 
language element in terms of the target language. 

It should be noted that the basic ideas of semantic 
specification are not nearly as well defined as those of 
syntactic specification. However, there are several charac¬ 
teristics which must exist in all semantic specifications. 

All that will be given here is an indication of an approach 
that could be taken to include semantic specification in 
the metalanguage already developed. 

The main function of a translator is to produce output 
which is based on the input. In a simple case, the output 
consists of input characters which are merely copied from 
the input stream, and certain target language constructions 
(for example, operation codes). Also, it is usually necessary 
to copy input characters in a different order from that in 
which they were recognized. This implies that there must be 
a mechanism for saving input characters for later use. 

A simple metasemantic language can now be defined. It 
consists of the symbols 'OUTPUT* and 'SAVE’, each followed 
by an operand enclosed in parentheses. The symbol 'OUTPUT' 
flags the operand following as an object to be put into the 
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output string. The symbol 'SAVE' flags the operand as 
something to be saved for later reference. The operand can 
be one or more of the following: (a) one or more target 
language base objects enclosed in quotes; or (b) a symbol 
of the form which refers to the input characters 

recognized as the n-th preceding syntactic element in the 
same statement. A symbolic metasyntactic statement which 
defines the syntactic type 'a' in terms of syntactic types 
' b' and 'c' can be written as 
a = (b + c)/b 

If symbolic semantics are included, this statement might 
appear as 

a = (b SAVE(. . . ) + c SAVE(...))OUTPUT{..,)/b OUTPUT{ 
To illustrate the use of the proposed metasemantic 
language further, the following metasyntactic statements can 
be constructed: 

statement = identifier + '=' + expression 
expression = identifier + '+' + identifier 
identifier = , A'/.../ , Z' 

An example of a statement written according to these rules 
is 'A=B+C f . A simple target language might include the 
symbolic operations 'CLA', 'ADD', and 'STO', each of which 
has a symbolic variable name as an operand. The statements 
above can be rewritten with semantic specifications as follows 
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statement - identifier + '=' + expression OUTPUT{'STO' *-3 

expression = identifier OUTPUT('CLA' *-l) + ' + ' + 
identifier OUTPUT ('ADD' *-l) 
identifier = *A' SAVE {*-!)/. ../'Z' SAVE(*-1) 

If this metalinguistic specification is applied to the input 
string A=B+C', the resulting target language output will be 

CLA B 
ADD C 
STO A 

The distinction between semantics and pragmatics must 
be made at this point. in the above example, the set of 
possible meanings of 'identifier 1 consists of the metasemantic 
constructions SAVE(*-1), which are associated with the syn¬ 
tactic types 'A' through 'z'. This set is called the 
semantics of the defined type 'identifier'. The pragmatics 
(a statement of which meaning will be used at a given time) 
of 'identifier' are implicit in the construction of the 
metalinguistic statement. That is, by writing a particular 
semantic construct beside a particular syntactic element, one 
of the set is chosen to be the particular meaning associated 
with that syntactic element. 

2.2.4 processor Considerations 

The most fundamental of the processor-dependent con¬ 
siderations is the question of how the syntax will be used 
in parsing. There are two approaches, called "top-down" 
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and "bottom-up". The top-down approach is analogous to 
assuming the structure of the input string before processing 
begins, and then attempting to verify that structure. The 
process begins with the head of the language and works down 
through the syntax tree to the base objects at the bottom. 

New characters from the input string are matched against the 
base objects as necessary. Meta II (4) is a top-down pro¬ 
cessor . The bottom up approach is analogous to assuming 
that the structure of the input string is unknown and is to 
be determined during the processing. The process begins 
with the characters in the input string, and the base objects 
at the bottom of the syntax tree. The processor then works 
up from the bottom of the tree toward the head of the language 
at the top. The Ingerman translator (1) uses a bottom-up 
approach. 

Another processor-dependent consideration concerns the 
order in which the metalinguistic statements will be presented 
to the processor. In most cases, the processor can be con¬ 
structed in such a fashion that this order is unimportant. 
However, it is sometimes necessary for a processor to require 
a certain ordering to accomplish a specific task. A hypotheti¬ 
cal example is to have the statements in alphabetic order by 
defined type. This notion of ordering does not affect the 
meaning of the statements. It merely simplifies some processor 
operation. 
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A further consideration concerns the order of alternative 
definitions for the same syntactic element. A processor must 
have some fixed order in which these alternatives are to be 
applied. The usual convention is to apply them in a left- 
to-right fashion. From the point of view of writing syntactic 
specifications this presents a problem. Consider a symbolic 
metasyntactic statement such as 
a = b/(b+c) 

which states that the defined type 'a' can be either the 
syntactic type 'b' or the construct 1 b' followed by *c'. If 
the input string is examined and the occurrence of syntactic 
type 'b' is found, the definition of 'a' has been satisfied. 
However, the second alternative will never be reached and 
thus the construct ' (b+c} 1 will never be found. This state¬ 
ment must be rewritten as 
a = (b+c)/b 

It should be noted that some metalanguages (e.g., the Ingerman 
metasyntactic language) do not provide a distinct alternation 
operator, but rather employ two or more definitions for the 
same defined type. The alternative definitions are inter¬ 
preted in some fixed order by the processor, say, from the 
top down. The same care must be taken in this scheme to avoid 
the problem of misordered alternatives cited above. 

Another processor problem occurs when recursive defini¬ 
tions are used in a top-down processor. This is known as 
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the "left recursion" problem. As an example, consider the 
following definition of 'identifier', 

identifier - (identifier + letter)/letter 
In this example, a top-down processor, in attempting to 
recognize the defined type 'identifier', will loop indefinitely 
trying to recognize 'identifier 1 . A possible solution is to 
replace recursion with the special symbol '$* mentioned in 
section 2.2.2. 

Another processor-dependent consideration has to do with 
the problem of failing to find a certain expected syntactic 
element. This is known as the "back-up" problem. The pro¬ 
cessor contains a pointer to the current syntactic element 
being added to the parsing tree. The term back-up refers to 
the backing up of this pointer to some previous step in the 
analysis when a failure occurs. As an example, suppose that 
an input string is being examined for the occurrence of a 
construct such as: 

d-type = s-typej/ s-type 2 / ... / s-type n , 

where 

s-type i * s-type ifi + ... + s-type^ 

At some stage the input string has been successfully matched 
with the given definitions up through 's-type^ ^_ 1 *, but upon 
examining the input string for the occurrence of 's-type i ^', 
the matching fails {j < m) . Either the input string must 
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b e declared ungrammatical, or the processor must back up to 
some previous point in the analysis and try an alternative 
definition. In some cases, the source language is such that 
back-up is not necessary {e.g., Meta II). This is the case 
when each syntactic unit being sought has a unique initial 
character. In most cases, however, the complexity of the 
language is such that back-up is necessary. The problems 
associated with back-up include not only the backing up of 
the processor to try a new goal, but also the backing up of 
the pointer to the corresponding previous source language 
character. Additionally, any output which may have been 
generated while tracing out the path which failed must be 
eliminated. 

The last processor-dependent consideration is the way 
in which the processor recognizes the basic character set of 
the source language. The syntax analysis phase of a translator 
really has two parts, a recognizer and an analyzer. The most 
basic recognizer is just a character picking routine, whose 
function is to supply the analyzer with a steady flow of 
input characters on which to operate. 

A slightly more complex recognizer could be given the 
task of setting a switch to tell the analyzer what kind of 
character this one is: a letter or a digit or a special 
character. A much more sophisticated recognizer might be 
given definitions of 'identifier' and 'number', and might 


- 
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recode these as simple operands for the analyzer (recoding 
them in a table and giving the analyzer a pointer to the 
table, for example) . Thus it can be seen that the two parts 
of the translator can stand in varying relationships to one 
another. The analyzer may have a basic symbol set which is 
actually some levels removed from the basic character set 
of the machine on which it is operational. In this case, 
the analyzer need be concerned only with kinds of things, 
not the things themselves. 

2.3 SYNTAX-CONTROLLED TRANSLATORS 

Syntax-controlled translators do not use the syntax of 
the source language in an explicit form. The original 
description of syntax, semantics, and pragmatics has been 
coded into some sort of tabular form, at least. They may, 
in some cases, be completely interwoven into the actual 
coding of the translator. 

Syntax-controlled translators are tailored to a particu¬ 
lar source-target language pair. Thus it is not possible to 
describe in any detail a general approach that may be taken. 
What will be described here are two approaches to the problem, 
using bounded context and operator precedence translation 
schemes as examples. 

Bounded context translation implies that at any given 
point during the translation process, the next step to be 
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taken is determined by the current source language element 
and N elements on either side of the current element, where 
N is dependent on the structure of the source language {11} , 
The same kind of thing can be said about syntax oriented 
methods; the action to be taken at any point depends on the 
current input element, and the structural relationships 
between all the previous input elements. However, in bounded 
context translation there is a fixed upper bound on the number 
of elements necessary to identify the input structure. 

A very simple example of bounded context translation can 
be constructed for translation of an arithmetic expression 
from (correct) complete parenthesis form to leading operator 
Polish form. (Complete parenthesis form is a notation in 
which all parentheses indicating hierarchy of operators are 
included.) A set of rules for this translation, using a left 
to right scan of the input, and only binary operators, is: 

1. If the input symbol is not a 1 )’, continue 
the scan. 

2. If the input symbol is a ')’, recode the 
preceding operand-operator-operand triplet 
as an operand of the form operator-operand- 
operand, and continue the scan. 

The usefulness of this scheme is limited, since one prefers 

to be able to use unary operators, and prefers not to use so 

many parentheses. However, it can be seen that, for this 

example, N is zero. That is, the action to be taken depends 

on only the current input element, and on none on either side 

of it. 
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Thi s scheme can be enlarged slightly by allowing the 
rules to specify "correctness", that is, that the operator- 
operand relationship must be of the form '(' operand 
operator operand ')'. Then the rules become 

1. If the input symbol is not a *)' , continue 
the scan. 

2. If the input symbol is a 1 )and the four 
preceding input symbols are: 

a. ' (' operand operator operand, then recode 
them as an operand of the form operator- 
operand-operand and continue the scan. 

b. otherwise, stop. 

In this case, N = 4, since at most four elements to the left 
of the current input symbol are necessary to determine the 
action to be taken. 

These informal rules can be rewritten in a more formal 
manner using Floyd’s productions (8), as follows: 

Production Action 

1. ( S © S ) A A Code P^ as 8 S S, i - i+1 

2. S S S S ) A -* empty Stop 

3. S A S = S S A 

Here 'S’ denotes any symbol whatsoever, B denotes any binary 
operator, and a list of recoded operand-operator-operand 
triplets. 'A' designates the position of the input pointer, 
where the current input symbol is just to the left of it. 
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The symbol '-*■' can be read "produces" or "becomes", applied 
to the input string. The set of productions is applied to 
the input string from the top down. When a production applies 
and the appropriate action has been taken, one returns to the 
top of the set and repeats the process. 

This is a compact and precise notation in which to write 
the rather wordy rules given before. Production 1 states the 
criterion of recoding, and the recoding to be done. Production 
2 is the "correctness" condition. Production 3 moves the input 
pointer, that is, it "continues the scan". 

Applied to the expression { (B*c) + ( (D*E)-F) ), the above 
productions would generate the set of P^ as 

P, = *BC P = *DE P - -P*F P = +P P , 

1 2 3 2 4 1 3 

which is the leading operator Polish string +*BC-*DEF . 

This sort of production scheme, recoded into a more 
amenable form for computer use, has formed the basis for a 
number of translators. It operates over a limited subset of 
the input string, and each action performed is dependent only 
on that subset. The emphasis here is not on the structure of 
the source language as a whole, but on the bounded subset 
with which each separate production is concerned. 

Another class of translation scheme often used in syntax- 
controlled methods is that of precedence analysis (12) (13), 
which is based on the precedence relations which hold among 
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the various operators in the language. This is a powerful 
method, and has been widely used in varying forms in many 
translators. However, it requires that the structure of 
the source language be implicit in the coding of the trans¬ 
lator, with the possible exception of the precedence 
relations, which may appear in tabular form. 

The basic idea of operator precedence analysis is 
illustrated by an example of a scheme for translating simple 
assignment statements to reverse Polish strings. The allowable 
operators are the source characters ' + ’, 

and ' + from lowest priority to highest. The only other 
allowable characters are single-letter variable names. The 
source statements are scanned from left to right by a pro¬ 
cessor which has one push down stack, called 0, used for 
stacking operators. 

The following procedure will generate as output the 
reverse Polish string representation of the input string. 

The top of 0 is denoted by 0^. The priority of an operator 
a is designated P(a). The current input character during 
the scan is denoted by the symbol S^. 0 t is initialized to 
the null operator, which has a priority lower than any other 
operator. 

1. If is an operator 

a. If P(S i ) < P (0 t ), put 0 t in the output, 
pop up 0. 
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i. If O t is the null operator, stop. 

ii. Otherwise, go to 1.a to repeat the test. 

b. If P(S^) > P(0 t ), push down 0, put in 0^., 
go to 1 to continue scan. 

2 . Otherwise, put in the output, go to 1 to 
continue the scan. 

If the above scheme is applied to the statement 
A=B*C + D*E-F,-, the reverse operator Polish string 
ABC*DE*+F-= will be generated. 

This type of scheme (in a much more complex form, of 
course) has been employed in the Algol GO translator described 
in (13). In that implementation, all source language de¬ 
limiters are given priority values. The source language 
translated is full Algol 60 (3) , with only minor exceptions 
(no dynamic own arrays or integer labels are allowed, and 
all formal parameters must have specifications). 

/ 

2.4 DISCUSSION OF SYNTAX-ORIENTED METHODS 

The most compelling aspect of syntax-oriented methods is 
that they augment the concept of the computer as a general 
purpose machine, by providing a base for the study of com¬ 
puter languages. As an exploratory tool, a syntax-oriented 
translator may be used in the design of new languages, or in 
the expansion, alteration, or replacement of source or target 
languages in the study of existing languages. It may be used 
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as an experimental compiler for the language under study. It 
provides a possible teaching aid in the explicit and precise 
statement of the characteristics of a source-target language 
pair. Finally, by its generality, it allows description of 
as large or as small a structure as desired. Thus any size 
"language" might be defined, from expression to statement to 
procedure to program. 

Syntax-oriented methods make bootstrapping fairly easy. 
Bootstrapping is the process by which a translator running 
on one machine can be used to produce the same translator to 
run on another machine. Suppose machine A has a syntax 
oriented translator written in source language L, and that 
the translation of L to some machine language can be ac¬ 
complished using translator T. The translator T requires 
two things: the metalinguistic specifications for a trans¬ 
lation, and the source language to be translated. If the 
source form of T is translated using metalinguistic specifi¬ 
cations for the L-to-machine-language-B translation, the 

result will be a translator T which will run on machine B. 

■ 

Syntax-oriented methods can be used as a possible means 
for investigation of the practicality of machine-independent 
translation. Machine-independence denotes what its name 
implies: independence from a particular machine. In using 

a translator, it is often desirable during the translation 
to be able to ignore some of the machine-dependent features 
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of the target language. A particular procedure-oriented 
language can be translated into some intermediate machine- 
independent form, which is designed to be easily translated 
into machine language for any particular machine. This has 
been a proposed method of operation for many years (14). 

The solution to the m language, n computer problem (which 
seems somewhat remote} could come from a scheme such as this. 
All procedure—oriented languages would be translated into 
some universal computer-oriented language, which could in 
turn be assembled or interpreted on the existing computers. 

It should be noted that syntax-oriented methods are 
actually at a higher level than syntax-controlled methods. 

A syntax- controlled translator is constructed for one source 
language and one target language. A syntax-oriented trans¬ 
lator is constructed for one metalanguage, which will permit 
description of a number of source-target language pairs. 

Lest we grow too enthusiastic about syntax oriented methods, 
however, let us consider some of the more obvious disad¬ 
vantages and criticisms. 

The main criticism of syntax-oriented methods is simply 
that they are inefficient. This has not been proved con¬ 
clusively, and may not be provable. However, it seems 
intuitive that the more general a method, the more inefficiency 
there will be for one specific use of the method. (Consider, 
for example, OS/360.) The most frequently cited reason for 
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tne inefficiency is that syntax-oriented methods will waste 
a great deal of time traversing some path through the syntax 
tree which ultimately turns out to be the wrong path (the 
"you can't get there from here" problem). Some progress has 
been made in this area, with the development of a technique 
for deciding whether or not a particular rule is applicable 
before actually applying it (applicable in the sense that 
use of it can lead to the current goal of the processor) (1) . 
Even so, general inefficiency with respect to any one trans¬ 
lation seems to be a reasonable assumption. It should be 
noted that syntax-controlled methods, since they are generally 
tailored to the source-target language pair involved, may be 
made as efficient as the programmer desires (or is able) . 

Another aspect of efficiency which may be considered 
is the efficiency of the resulting target language that is 
produced by a translator. Some of the more common means of 
achieving some measure of efficiency are (a) elimination of 
recomputation of common subexpressions; (b) the removal of 
invariant computations in a loop to outside the range of the 
loop; (c) the elimination of redundant instructions; and (d) 
the efficient utilization of hardware such as accumulators 
and index registers. The point has been made (9) that target 
code generated during a syntax-oriented analysis of the source 
language cannot be efficient, because it is difficult to 
provide for the above optimization of the target code. It 
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is possible that a partial solution to this problem might 
be to generate target code that is suitable for optimization 
by a later processor. 

Another complaint about syntax-oriented methods is the 
difficulty in producing source language diagnostics when the 
input string is ungrammatical. There have been several 
partial solutions to this problem cited as having been tried 
(9) . Among them is a scheme {15) which, when presented with 
an incorrect input string, will make "local" insertions and 
deletions in the input string until a syntactically correct 
string is produced. 


_ 
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3. INGERMAN 1 S TRANSLATOR 

3.1 INTRODUCTION 

This section describes the translator which has been 
written to implement the techniques developed by Ingerman 
(1). The presentation here is a fairly general one, with 
specific attention paid to the basic philosophy used in the 
parsing processor. The notation used is that used in the 
implementation. For more details of any particular point, 
consult either the description and listing of the PL/I program 
in Appendices 6.2 and 6.5, or reference (1). 

The translator consists of three parts: a metalanguage 
input routine, the syntax analyzer (or parsing processor) , 
and the semantic output generator (or unparsing processor) . 

The basic philosophy used in the translator is to analyze 
the source language input string according to the syntactic 
rules provided to the translator. Then, if the input string 
is determined by the processor to be syntactically correct, 
the translator will generate target language output based on 
the analysis of the input string, and the rules of semantics 
and pragmatics which are also provided to it. 

The metalanguage input routine has the task of reading 
in the rules, written in the syntactic and semantic meta¬ 
languages. It also constructs a table called the acceptability 
table, for use by the parsing processor. 






-29- 


The parsing processor has two purposes. The first is 
to determine the correctness of the source language input 
string. The method by which the parsing processor analyzes 
the input string is basically a "bottom-up" method. The 
processor selects a goal which is one of the defined elements 
in the syntactic rules {initially the head of the language) . 

It then attempts to follow a chain of syntactic rules from 
the current base objects in the input string toward the goal. 
As the chain of rules builds up, more base objects from the 
input string are required by the rules, and sub-goals at 
lower levels of the parsing tree are established. For a 
valid construction, the head of the language is reached at 
the same time the source language input string is exhausted. 
The parsing processor makes use of the acceptability table, 
which is constructed from the syntactic rules. It is used 
to decide whether or not the parsing processor can reach the 
current goal from the current position in the syntax tree. 

This table can save a great deal of "useless 11 time spent 
tracing out rule chains which will ultimately fail because 
they cannot possibly lead to the current goal. 

The second purpose of the parsing processor is to provide 
the unparsing processor with a complete description of the 
relationships between all the base objects in the input 
string. It does this by constructing a list of the rules 
which have been successfully applied, which is then passed 
on to the unparsing processor. 
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The unparsing processor has as its function the actual 
translation according to the rules of semantics and pragmatics 
that are supplied to it. These are directly associated with 
their respective syntactic rules used in the parsing processor. 
Thus the list of rules applied by the parsing processor gives 
the order of rules to use in unparsing. The semantic and 
pragmatic rules actually provide the "meaning" of the source 
language constructs in terms of the target language. The 
term "meaning”, in the framework of a translator, denotes the 
production of output which represents the mapping of the 
source language onto the target language, according to the 
syntactic, semantic, and pragmatic rules supplied. 

The lowest level of semantic specification consists of 
base objects which are simply to be placed as is in the output 
string, and various special characters which control the 
spacing of the output. The next level consists of metasemantic 
constructs which are called clauses. Clauses actually refer, 
within one metasemantic rule, to the relationship of the 
various metacomponents of the metasyntactic rule which was 
used to analyze the string. Combinations of base objects 
and clauses of varying complexity are used to specify the 
output, which might be, for example, symbolic machine language. 

In summary, the translator consists of an input routine, 
and two main phases, the parsing processor and the unparsing 
processor. The parsing processor has two purposes: to 
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aetermine the correctness of the input string, and to produce 
a parsing tree. This tree contains a complete description of 
the interrelationships between all the objects in the input 
string. These interreleationships are then used by the 
unparsing processor to determine the set of meanings which 
may be attributed to the objects, and to produce as output 
the particular meaning selected by the pragmatics. 

3.2 SPECIFICATION OF SYNTAX 

The formation of metasyntactic rules is based on the 
notion of base objects and defined types discussed in Section 
2.2. The basic formation of a metasyntactic rule, is, from 
left to right, one or more metacomponents, followed by the 
metaresult which they define. Metacomponents may be either 
base objects, which will be represented here as one character 
delimited by single quotes, or defined types, which will be 
represented here as one to four capital letters (to correspond 
to the implementation) . A simple rule to define the character 
■A’ as a ’letter' might be written as 
'A' L 

where the name L is an abbreviation understood to mean 'letter' 
It is immediately obvious that a base object cannot be a 
metaresuit. A rule may have more than one metacomponent, as 
in the rule 

LPL AE AS 

which defines an 'arithmetic-statement' as being a 'left- 
part-list' followed by an 'arithmetic-expression'. 
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Base objects which are considered to have no explicit 
meaning within the syntactic structure, but are simply objects 
which are expected to appear in the input string at certain 
points, may be used as metacomponents, as in the rule 
ID ' = * LP 

which states that an 'identifier' followed by the object *=’ 

is a 'left-part'. On the other hand, if a base object is to 

be referred to in a more general way, then it should be given 

a name, as in the two rules 

' + ' AO 
AO 

which state that the objects * + * and are both to be known 

as 'adding-operator*. 

Recursive rules may be constructed? that is, a defined 
type which is a metaresult in a certain rule may be a meta- 
component of that same rule. For example, a rule which might 
partially define 'identifier' is 
ID L ID 

It should be noted that the rules must satisfy the 
conditions stated in Section 2.2: (1) there must be at least 

one metaresult which is not used as a metacomponent in any 
rule (this is the head of the language) ; (2) all metaresults 

must be reducible to a set of base objects (there is a 

stronger statement of this "grounded" condition which will 

« 

be made shortly); (3) all metacomponents which are defined 

types must be used as metaresults in at least one rule. 
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The set of syntactic rules for a simple assignment 
statement is given in Table 2. It is a direct translation 
of the rules given in Table 1. Table 3 contains a listing 
of the same rules in a proper order for the Ingerman pro¬ 
cessor. (This is a requirement of the current implementation 
See Appendix 6.2 for details.) These rules allow identifiers 
consisting only of letters, and only integer constants. 
Otherwise they are the same rules that are incorporated in 
the larger {but still simple) language listed in Appendix 6,2 

It has been stated that the parsing processor determines 
a goal (initially the head of the language) and attempts to 
build a chain of rules from the current source language input 
string to that goal, establishing sub-goals and examining 
input characters as necessary. Having described how to form 
rules of syntax of the source language, it is now necessary 
to consider the notion of a rule chain, in order to describe 
the construction of the acceptability table. 

A rule chain may be defined as "a sequence of rules such 
that the metaresult of the k-th rule is one of the metacom¬ 
ponents (or the sole metacomponent) of the (k+l)-st rule" (1) 
A rule chain is said to have a loop in it if the metaresult 
of one of the rules is a metacomponent either of a rule 
preceding it in the rule chain, or of itself. If a rule 
chain has a loop in it, at least one metacomponent of one of 
the rules in the loop must require a new base object from 
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TABLE 2 


LANGUAGE OF ASSIGNMENT STATEMENTS 
RE-WRITTFN IN INGER MAN'S NOTATION. 


1 

L P 

AE 

AS 



2 

I n 

EO 

LP 



3 

UAE 

AE 




4 

AF 

DAE 

AE 



5 

T 

AE 




ft 

AO 

T 

U AE 



7 

F 

T 




a 

T 

MO 

f r 



9 

P 

F 




10 

F 

ES 

P F 



u 

I D 

P 




12 

U I 

P 




13 

L PN 

AE 

RPN P 



14 

L 

ID 




15 

I 0 

L 

I D 



16 

0 

UT 




17 

U I 

D 

UI 



18 

* +' 

AO 


NOTE 

: THESE SYNTACTIC RULES 

19 

» _• 

AO 


AlE 

TN THE SAME ORDER AS 

20 

t «• 

MO 


TABLF 1. THIS IS A 

21 

• /• 

MO 


•TOP 

DOWN* ORDERING, AND I S 

22 

• A' 

L 


NOT 

ACCEPTABLE FOR THF 

23 

* B * 

L 


INGERMAN PROCESSOR. 

24 

• C» 

L 




25 

• O' 

L 




26 

• F* 

L 




27 

• F* 

L 


ABBREVIATIONS USED: 

28 

• W* 

L 




29 

* X' 

L 


LP 

LEFT-PART 

30 

t Y« 

L 


AE 

ARITHME TIC-EXPRESS!ON 

31 

' 7 ■ 

L 


AS 

ASSIGNMENT-ST ATE ME NT 

32 

• 0» 

D 


TO 

IDENTIFIER 

33 

* 1 * 

D 


EQ 

EQUAL-SIGN 

34 

' 2 ' 

D 


UAE 

UNARY-ARlTHMCTIC-EXPR. 

35 

' 3' 

0 


T 

TFRM 

3ft 

* 4' 

0 


AO 

ADO ING-OPERATOR 

37 

. «ji 

D 


F 

FAC TOR 

38 

» ft* 

0 


MO 

MULTI PLY INS-OPERATOR 

39 

* 7* 

D 


P 

PRTMARY 

40 

* 8' 

0 


FS 

EXPONENTIATION-SIGN 

41 

i qt 

D 


UI 

UNSIGNED-INTEGER 

42 

f3* 

FO 


L PN 

lfft-parfnthfsts 

43 

• | • 

ES 


RPN 

RIGHT-PARENT4F SIS 

44 

• (' 

L PN 


L 

letter 

45 

■ ) ' 

RPN 


0 

DIGIT 
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table i 

LANGUAGE OF ASSIGNMENT STATEMENTS IN 
PROPER ORDER FOR INGERMAN PROCESSOR. 


I 

L P 

AE 

AS 

7 

I D 

EQ 

IP 

3 

I 0 

L 

1 D 

4 

I D 

P 


5 

UA 6 

AF 


6 

AE 

UAE 

AF 

7 

AO 

T 

UAE 

8 

F 

ES 

P 

9 

F 

T 


10 

T 

MO 

F 

11 

T 

AE 


12 

P 

F 


13 

U I 

0 

UI 

14 

U I 

P 


15 

L PN 

AE 

RPN 

16 

L 

ID 


L7 

0 

UI 


18 

• + • 

AO 


19 

i , i 

AQ 


20 

• * * 

MO 


21 

* /* 

MO 


22 

» A* 

L 


23 

• B* 

L 


24 

• C* 

L 


25 

* 0 » 

L 


26 

• E* 

L 


27 

. fr t 

L 


2 B 

. w . 

L 


29 

• X* 

L 


30 

i y i 

l 


31 

* Z* 

L 


32 

• 0 * 

D 


33 

• 1 ' 

0 


34 

■ 2 ’ 

0 


35 

• 3 • 

D 


36 

i 4 * 

D 


37 

* 

D 


38 

• 6 * 

D 


39 

t 7 . 

D 


40 

« fi’ 

0 


41 

« < 5 . 

D 


42 

t - t 

eo 


43 

* ! * 

FS 


44 

* I' 

IPN 


45 

* > • 

RPN 
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the input string, or the processor will loop indefinitely. 
(This is the stronger statement of the "grounded" condition 
referred to previously.) it should be noted that the only 
rule in a rule chain which may have only base objects as 
metacomponents is the leftmost rule. 

As an example, consider the (sub)set of rules 


1. 

’A' 

L 


2. 

ID 

L 

ID 

3. 

L 

ID 


4. 

ID 

i _ i 

LP 

5. 

LP 

AE 

ST 


If the current goal is ST, and the current input character 
is 'A', then the rule chain 1-3-4-5 is one of the possible 
rule chains from the current input character to the current 
goal. 

In the same example, another rule chain from 'A' to 
ST is 1-3-2-4-5. This rule chain contains a (simple) loop, 
since rule 2 has ID as both a metacomponent and the metaresult. 
Less trivial loops can be found in the rules of Table 1. For 
example, the rule chain 3-S-6-7 forms a loop containing 
'arithmetic-expression', 'term', 'factor', 'primary', 
’arithmetic-expression'. This same chain also contains other 
loops. 

3.3 THE RULE INPUT ROUTINE 

The rule input routine reads in the metalinguistic 
statement of the translation desired. Since it is a rather 
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clumsy process to work with the rules in their character form, 
they are recoded into a form more suitable for processing. 

This is done by constructing a list, P, of all the metacom¬ 
ponents used in the rules, both base objects and defined 
types. The rules themselves are recoded by substituting a 
pointer to the appropriate element of P for each element of 
each rule. Corresponding to P are several auxiliary lists 
which provide information such as (a) whether or not this 
element is used as a leftmost metacomponent, and if so, which 
rule is the first rule in which this is so; (b) whether or 
not this element is a base object or a defined type; (c) 
whether or not this element is the metaresult of some rule, 
and if so, what is the corresponding column in the accept¬ 
ability table. 

The rule input routine also constructs the acceptability 
table, which is designed to answer the following two questions 
which the parsing processor will ask. (i) Is there a rule 
chain with this rule as the leftmost rule that leads only 
through leftmost metacomponents to the current goal? {id) 

Is there a rule chain from this rule (which has more than one 
metacomponent) to the current goal? 

The acceptability table is a Boolean matrix. The column 
headings of the matrix are all the defined types which are 
used as metaresults. The row headings are all the metacom¬ 
ponents, both base objects and defined types. The matrix is 
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constructed in the following way. Every rule is examined, 
and a one put in each matrix element that has as its row 
heading the leftmost metacomponent of the rule, and as its 
column heading the metaresult of the rule. Then each column 
of the matrix is examined. If there is a one in a column, 
then that row is logically OR-ed with the row which cor¬ 
responds to that column of the matrix. The matrix thus 
produced will answer the question, "Is there a rule chain 
with this rule as the leftmost rule which leads only through 
leftmost metacomponents to the current goal?" 

In order to answer the second question, it is necessary 
to treat each non-left metacomponent which is a defined type 
as a separate element. A new row is added to the matrix for 
each use of each non-left metacomponent, and a one put in the 
column headed by the metaresult of that rule. The OR-ing 
procedure is applied to the additional rows of the matrix. 
This matrix will now answer the second question, "Is there a 
rule chain from this rule (which has more than one metacom¬ 
ponent) to the current goal?" In addition, each use of a 
metacomponent as a non-left metacomponent must be added to 
the list P as a new defined type, and the coding of the 
particular rule changed to point to this new element of P, 
rather than the original one. Thus each use of a metacom¬ 
ponent as a non-left metacomponent is treated as if the 
metacomponent were a new and different defined type in the 
language. 





3.4 


THE PARSING PROCESSOR 


The basic philosophy of the parsing processor is to trace 
a path from the base objects found in the input string through 
the syntax tree to the head of the language at the top of the 
tree. The processor is initialized by choosing the initial 
goal to be the head of the language. The starting point for 
the search for a rule chain to the goal is chosen to be the 
first character of the input string. Before a more detailed 
description of the process is given, two important points 
should be discussed. 

The first point concerns the rationale followed in 
choosing a new rule to apply. When it is necessary for the 
parsing processor to choose a new rule, it will know one of 
two things: either the current character in the input string, 
or the last rule successfully used (that is, the last defined 
type recognized in the input string). Since the metasyntactic 
rules are constructed in a left-to-right fashion, an obvious 
rule to apply is one in which the leftmost metacomponent is 
either the current input character or the last defined type 
successfully recognized. At this time the acceptability table 
can be used to determine the possible applicability of this 
rule. (The acceptability table was constructed to answer the 
question, "Is there a rule chain (with this rule as the left¬ 
most rule) which leads only through leftmost metacomponents 
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to the current goal?") The acceptability table is entered 
with the leftmost metacomponent of this rule as the row 
index, and the current goal as the column index. If the 
selected element is a one, then a rule chain exists, and this 
rule is at least a possible link in the rule chain. 

As an example, consider the following rule, which defines 
the metaresult 'MR1 1 to be a series of two metacomponents: 

MCI MC2 MRl 

If ’MCI 1 is the metaresult of the last rule successfully 
a Ppli e< ^f an£ ^ 'MRl' is the current goal, then the acceptability 
table will indicate that this rule is applicable. 

The second point concerns the further processing of a 
rule after it has been determined to be possibly applicable. 
The acceptability table has already provided the information 
that it is possible to reach the current goal from a rule 
which has a particular leftmost metacomponent. If a rule has 
more than one metacomponent, it is possible that one of the 
non-left metacomponents is not applicable (and thus that the 
whole rule is not applicable) . Thus these non-left metacom¬ 
ponents must be examined. Metacomponents which are base 
objects are simply compared to the current input string 
character to determine if this rule applies. Metacomponents 
which are not base objects must be examined further. In fact, 
a non-base object, non-left metacomponent must be established 
as a new (sub) goal, and the input string examined for the 
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occurrence of this defined type. However, the acceptability 
table was constructed to answer the additional question, "Is 
there a rule chain from this rule (which has more than one 
metacomponent) to the current goal?" Thus, before the pro¬ 
cessor actually examines the input string, the acceptability 
table can be entered with this use of this (non-leftmost) 
metacomponent as a row index, and the current goal as a 
column index. If the selected element is a one, then there 
is a rule chain to the goal which includes this rule (and 
this non-leftmost metacomponent) . 

As an example, consider the following two rules defining 
the metaresults 'MRl' and *MR2', both of which have the same 
left-most metacomponent. 

Rule 1: MCI MC2 MRl 

Rule 2: MCI MC3 MR2 

If 'MR2 1 is the current goal, and 'MCI 1 the last metaresult 
successfully found, the acceptability table will indicate 
(in answer to the first question) that Rule 1 is applicable, 
because there is a rule chain (with MCI as a leftmost meta¬ 
component of the leftmost rule) to the goal MR2. It is not 
until the second metacomponent of Rule 1 is examined that it 
is found that the rule is not applicable. 

A flowchart of the philosophy of the parsing processor 
is given in Figure 1. This flowchart omits most of the details 
of the processor. It is intended to indicate the logical steps 
taken by the processor. The flowchart is self-contained, 
except for two "exits", Output and Recover . 
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Tne routine called Output has the function of recording 
the rules used in the successful completion of a rule chain 
to some (sub)goal. 

The routine called Recover has the function of recover¬ 
ing from an unsuccessful attempt at applying a rule. If a 
rule is found to be inapplicable, there are two possibilities: 
either there is another rule which has the same metacomponents 
to the left, or there is not, if there is such a rule, then 
that rule can be tried. If there is not, it is necessary to 
back-up to some previous level, and try an alternative rule 
at that level. It may be that ultimately the input string 
will be found ungrammatical; the processor will recover from 
unsuccessful attempts at parsing until it is back at the 
beginning, with no more alternatives to try. In this case 
it must stop, with suitable indication that the input string 
is bad. On the other hand, the processor may find, at some 
previous level, another path to follow which will lead to 
the successful conclusion of the parsing. 

Throughout this discussion, the method in which the 
parsing processor keeps track of the various pieces of 
information that it needs has not been mentioned. Information 
is required both to recover from an unsuccessful attempt at 
applying a rule, and to construct the necessary parsing tree 
form of the input string for use by the unparsing processor. 
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There are a number of stacks which are manipulated by the 
processor to accomplish both of these things. The use of 
several of the stacks is described as follows. The stacks 
GOAL, INPUT, and OUTPUT are pushed down each time a new 
subgoal is established. They are popped up when the pro¬ 
cessing of the current subgoal is complete (whether successful 
or not) . The stacks RULE and CONSTITUENT are pushed down each 
time a metacomponent is successfully recognized. They are 
popped up during both generation of output and recovery 
from an unsuccessful application of a rule. The stack LINK 
points to the element of OUTPUT which is the head of the 
subtree just successfully parsed. 

The list called PARSE contains the rules generated by 
the parsing processor. It is essentially the Polish string 
form of the parsing tree. The list is generated in such a 
fashion that, when parsing is complete, each element of the 
list which corresponds to the metaresult of a rule is followed 
by exactly as many entries as there are metacomponents in the 
rule. Each entry is either a rule number, or a pointer to 
another section of the list which contains the appropriate 
rule number. The final element of the list will always be 
a pointer to the rule which was used to define the head of 
the language. Table 4 gives an example of an input string 
which has been parsed according to the rules stated in Table 
3. Also included is the list of rule numbers with their 
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associated rules. (in Appendix 6.4 is a complete set of 
input, including the rules of Table 3, and several source 
language input strings to be parsed according to those 
rules. Appendix 6.5 is a listing of the output of the 
processor corresponding to this input). 

The most important features of the parsing process have 
now been discussed. The processor itself consists of four 
main sections to handle the four general situations which 
may arise. The sections are: (a) the initialization section, 
which has as its function the initialization of a defined type 
as a new subgoal; (b) the processing section, which attempts 
to build a rule chain from the current source language input 
string to the current subgoal, which was established by the 
initialization section; (c) the recovery section, which has 
the function of recovering from an unsuccessful attempt at 
applying a rule; and (d) the output section, which has the 
function of recording the rules used in a successful comple¬ 
tion of a rule chain from the current characters in the input 
string to the current subgoal. 

3.5 THE METASEMANTIC LANGUAGE AND PRAGMATICS 

From the previous section, we have seen that parsing 
consists of establishing the grammatical relationships between 
all of the source language input string characters. The 
output of the parsing processor is an ordered list of all 
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the rules that were applied. The list elements for each rule 
consist of as many elements as there are metacomponents of 
the rule. Each element is either a rule number, or a pointer 
to another part of the list where the rule number will be 
found. This list provides a description of the structure of 
the input string. What is needed now is some means of attach¬ 
ing meaning {in terms of the target language) to this 
structure. This is accomplished by associating with each 
syntactic rule an additional semantic rule, written in a 
metasemantic language. The manner in which the semantic rules 
are used constitutes the pragmatics. 

The parsing processor constructed rule chains from the 
bottom up, until it finally reached, as a goal, the head of 
the language. The output list of the parsing processor was 
generated in this order also, with the last element of the 
list being a pointer to the highest level used, that is, the 
rule which defines the head of the language. 

The unparsing processor uses this list in the reverse 
order from that in which it was constructed; that is, the 
unparsing processor starts at the rule defining the head 
of the language, and progresses in a direction that is 
downward throught the syntax tree. 

The purpose of a metasemantic language is to allow the 
user to state the semantics of the source language in terms 
of the target language. The metasemantic language developed 
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by Ingerman can be described fairly easily. Its use , which 
constitutes the pragmatics, cannot be described easily except 
by example. Some examples will be given in the discussion of 
form of the metasemantic language. 

A metasemantic rule is a construct, delimited by broken 
brackets < and 1 > ' . The simplest construct is the null 
element, or <>. Another construct consists of one or more 
target language output characters, delimited by quotes, as 
<’A'>. Thus a complete metalinguistic definition of the 
character A as a letter is 

'A' L <’A'> , 

which says that 'A' is a letter, and the base object 'A' is 
to be placed in the output when this rule is applied. These 
are considered to be "terminal” constructs, in the sense that 
when the processing of one of them starts, it is not necessary 
to process another construct in order to complete it. 

A third type of construct is the “punctuation" of the 
output. Unless one of the punctuation symbols is used, the 
output character(s) will be placed in the next available 
position(s) in the current "line" of output. The punctuation 
which may be used consists of three symbols, a, B, and y, 

(For a specification of what characters are used to represent 
non-keypunch symbols in the implementation, consult Appendix 
5, the description of the PL/I program.) The meaning of the 
symbols is as follows, considering the output to be produced 
on a standard printer: 
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a - prepare for characters starting in position 
1 of the line (if currently past position 1, 
print the current line first). This is used 
for output of labels in symbolic machine 
language. 

6 - prepare for characters starting at position n 

(where n is a constant specified in the program); 
if past position n, print the current line first. 
This is used for output of symbolic operation 
codes. 

y - prepare for characters starting at the position 
which is the next largest multiple of n. This 
is used for output of operand fields. 

The next higher type of construct is known as a clause, 

and provides a means for describing how a construct is as¬ 
sociated with its environment in the parsing tree. The 
simplest type of clause is a direct reference to components 
of the metasyntactic rule with which it is associated. The 
reference is made by considering the elements of the meta¬ 
syntactic rule to be numbered from right to left, starting 
with zero for the metaresuit. Only defined types are numbered; 
base objects are omitted from the numbering scheme because they 
are of no semantic importance. The index numbers are then used 
in constructing the metasemantic rule. As an example, con¬ 
sider the following metalinguistic rule, which defines a 
statement to be a variable followed by an equal sign followed 
by an expression: 


VAR 

( 2 ) 


I _ I 


EXP ST 
( 1 ) ( 0 ) 


<(1) S 'STORE' Y (2) > 
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What the metasemantic rule states is that first the chain of 
rules which defines EXP should be followed; then the base 
object 'STORE' should be put into the operation code field 
of the output, followed by the results of the definition of 
VAR in the operand field. Presumably the rule chain defining 
EXP will generate coding which will leave a value in a 
register, which will then be stored by the 'STORE' command. 
The rule chain defining VAR will produce an address in which 
to store it. 

A more complicated form of the clause introduces a new 
kind of metasemantic element, the dummy variable. This 
allows a construct to define alternate meanings for a meta¬ 
component, one of which will be selected by some lower level 
construct. The general form of a construct defining dummy 
variables is 

where n is the index of some metacomponent of the associated 
syntactic rule, D 1 is the first dummy variable followed by 
its definition, D.. the second, followed by its definition, 
followed by any number of others, followed by more of the 
construct. What this says is essentially that if, in the 
following of the rule chain associated with the n-clause, the 
dummy variable D- t is found in some lower level construct, 
substitute for it the definition following the D i in the 
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construct, and similarly for D z , etc. As an example, consider 
the adding operators ' + ' and , the rules which define them, 
and a metasemantic construct which makes use of dummy vari¬ 
ables to differentiate between them. The rule defining 
'arithmetic-expression' to be a ’unary-arithmetic-expression' 
requires that the two operators be treated differently. In 
the case of the unary ’+ 1 , the sign is to be ignored. In 
the case of the unary the sign of the operand must be 

reversed {by a "change sign" instruction CHS, for example) . 

The following three rules from Table 5 illustrate the 
use of dummy variables to make this distinction: 


UAE 

AE 

<(1,A,S 1 CHS')> 


AO 

<h> 

f _ 1 

AO 

<S> 


What this says is that if, in following the rule chain 
associated with the 1-clause, the dummy variable A is found, 
substitute the null element for it. If the dummy variable 
S is found, substitute the base objects 'CHS' for it. Prom 
this it can be seen that the possible dummy variables that 
may be encountered are defined in some higher level construct, 
and then, when one of them is encountered, the appropriate 
substitution is made. 

Table 5 gives a listing of the rules of Table 3, with 
the semantic rules for the generation of appropriate symbolic 
machine language. Table 6 gives a description of the symbolic 
machine language and the machine on which it is to run. Table 
7 gives the output generated by the unparsing processor for 
the example of Table 4. 
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TABLE 5 


RULES OF TABLE 3 WITH SEMANTICS. 
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TABLE 6 


A Simple Stack Machine 

t 1 denotes the top of the stack, t 2 the next to the top, 


Operation Code 


Operation 


ADD 

fc 2 


*1 

replace 

t 2 ' 

stack 

is 

popped 

up 

SUB 


- 


replace 

t 2 , 

stack 

is 

popped 

up 

MPY . 

t 2 

* 

*1 

replace 

fc 2 ' 

stack 

is 

popped 

up 

DIV 

t 2 

/ 


replace 

t 2 ' 

stack 

is 

popped 

up 

EXP 

t 2 

+ 


replace 

t 2 ' 

stack 

is 

popped 

up 

CHS 

LOAD m 

-t, replaces t : 

stack is pushed 

down 

, contents of m 

replace t 1 

STORE m 


replaces contents 

of m. 

stack is 

popped up 
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TABLE 7 


Output Generated In Translation Of 
A = B+C*D/E+F 

LOAD B 
LOAD C 
LOAD D 
MPY 

LOAD E 
LOAD F 

EXP ( 

DIV 

ADD 

STORE A 
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3.6 THE UNPARSING PROCESSOR 

The unparsing processor uses the semantic and pragmatic 
rules to generate the output of the translation. It must, 
of course, also have the output of the parsing processor, 
wnich consists of the list of rules used in the parsing (named 
PARSE). 

The unparsing processor has a number of stacks to keep 
track of the current rule, the position within that rule, 
the level at which the processor currently is within the 
parsing tree (this is initially zero, and when it returns to 
zero, the unparsing is complete), and other information. 

The basic method used is to choose a rule from the list 
PARSE, and then interpret the metasemantic part of the rule. 

It has been noted that in the list PARSE, each metaresult is 
followed by exactly the same number of entries as there are 
metacomponents of the rule. This fits in nicely with the 
numbering scheme used in the metasemantic language. That is, 
when a 1-clause is encountered in the semantic rule, the 
processor looks at the next sequential element of the list 
PARSE for the rule number to use. When a 2-clause is 
encountered, it looks at the second element of PARSE, and so 
on. 

3.7 EXTENSIONS TO THE METALANGUAGES 

Extensions to the metasyntactic language are implemented 
by what are called metasyntactic functions (MSF's) . The general 
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method for implementing such MSF's requires modification of 
the processor to interpret them. in general an MSF is 
attached to a metacomponent of a rule. MSF's may be either 
prefixed or suffixed to the metacomponent to which they are 
attached. Some of the MSF's suggested by Ingerman are (a) 
the substitution MSF, which allows substitution of any set 
Oj. base objects (or the null element) for any occurrence of 
a subset of the set of base objects in the input string; 

(b) the right context MSF, which allows re-scanning of the 
same input character by different defined types; and (c) the 
class-instance MSF, which allows recognition of instances of 
things which are of the same class. The only one currently 
implemented is the right context MSF. 

An example of the use of the right context MSF is in 
recognizing that an 'identifier' may be terminated by a 
special character, as in the following rules from Appendix 2: 

L IDl 

IDl L ID1 

IDl SPC <1> ID 

The <1> suffixed to the metacomponent SPC is the implementa¬ 
tion symbol for the right context MSF. Its function is to 
back up the input pointer after the recognition of the special 
character. If this were not done, the special character (an 
'** for example) would be lost to the parsing processor. 

Metasemantic and pragmatic functions (MPF's) allow 
additional meanings to be associated with syntactic rules in 
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m°re extensive ways than have been mentioned, MPF's also 
require modification of the processor in order to interpret 
tnem. MPr s are denoted by #n (in the current implementation 
n lies between 1 and 3) . The MPF’s which are currently 
implemented are (a) #1, which generates a unique label; (b) 

#2n, which regenerates the n-th preceding label generated 
by irl, and (c) #3T, which can be used to generate temporary 
storage labels based on the number of occurrences of the 
dummy variable T* 

A problem encountered in translation is that of processing 
type declaration statements. Declaring a variable to be of a 
certain type is essentially a metalinguistic specification 
which is made by the particular source program being trans¬ 
lated (1) (9). In order to process such a specification, it 

is necessary to generate rules which define the variable to 
be of the specified type. These rules are added to the rule 
set, and then another pass through the translation process 
is made using these rules. Included in the metasemantic 
language are special constructs which allow the generation 
of new rules. 

3.8 COMMENTS ON INGERMAN’S METHOD 

Enough of the method of translation has been discussed 
to be able to say a number of things about it. In general, 
the approach is an interesting one with the rules of syntax 
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and semantics being interpreted essentially in their original 
^orm by their respective processors. The metasyntactic 
language is sufficiently clear as to be fairly easily grasped 
by a new user of the translator. The notion of the accept¬ 
ability table to determine the applicability of a rule is a 
fine one. However, there are a number of weak points in the 
whole process, some of which are discussed below. 

From the user 1 s point of view, the metasyntactic language 
is confusing at first, since the metacomponents are to the 
left of the metaresult, but are interpreted from left to 
right. It would not be difficult to change the design of 
the translator, or of the input routine, to allow input of 
rules with the metaresult on the left, and some (possibly 
ignored) operator which denotes the fact that what follows 
defines this metaresult. 

As mentioned above, the idea of the ordering of the 
rules being done internal to the processor is a fine one. 
However, there are questions of the resolution of ambiguity 
by a certain order of rules, and the ordering algorithm may 
possibly change this ordering, thus changing the "meaning" 
of the rules. This would resolve the ambiguity in a way 
different from that intended by the user. 

It is not clear how "reserved words" in a language 
should be specified. An example of a specification that 
works, but is clumsy, is 
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*R' R 
'R' L 

R ’ E ’ 'A' 'L' REAL 

This is not a very satisfactory solution to the problem, 
which is a common one. Perhaps an MSF could be devised to 
handle this. Or perhaps some use of the substitution MSF 
would solve the problem. 

The metasemantic language seems to be "complete" in 
some sense of the word. The user may produce output pretty 
much as he pleases. However, it is not an easy language 
with which to become familiar, and it is clumsy to use once 
one is familiar with it. Perhaps a better notation for the 
same ideas could be developed, which would make the language 
look more like something meaningful, and less like a random 
bunch of- characters on first viewing. 

The facilities for including special metasyntactic and 
metasemantic functions are limited. In order to include 
them, a specific knowledge of the processor involved is 
necessary. It is not clear that this could be avoided, but 
some thought should be given to "object time" specification 
of special functions, perhaps using the dynamic invocation 
of the PL/I compiler to implement this. 

3.9 EXTENSIONS TO THE METHOD 

From the discussion of the previous section, it is clear 
that there are a number of improvements that could be made to 
both the technique and the current PL/I implementation. Some 
of these are listed below. 









“60- 


A more easily understood metalanguage which would 
ue direct input to the rule input routine should be designed. 

simplest, this would require a few minor modifications 
ana additions to the existing input routine. At worst, it 
might require a whole new approach to the problem of pro¬ 
cessing the metalanguage - a compiler for the metalanguage, 
perhaps. 

(2) The question of what effect the automatic ordering 
of rules has on the definition of the structure of the source 
language should be investigated. If the user intends to 
prescribe a certain ordering for a particular resolution of 
ambiguity, then he should be allowed to specify that as his 
intent, and override the automatic ordering. 

(3) The additional MSF’s and MPF's that are described 
in Ingerman's book should certainly be implemented. They 
allow processing of more complicated structures such as 
FORTRAN DO-loops. 

(4) The question of source language diagnostics from 
the parsing processor needs investigation. The diagnostic 
"BAD" is a bit too terse for most users of a translator. It 
would seem that at least a brief trace of the path taken in 
reaching the BAD point could be constructed. Perhaps, with 
some study, an algorithm for actually diagnosing the problem 
could be devised. 
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(5) it would be interesting to attempt to determine 
whau languages Mr- Ingerman's scheme is-sufficient for, and 
what additional capabilities are necessary in order to process 
languages of more complexity, or of more "pathologicar 1 
StruLLure. Another side of this question is what sort of 
pathological languages will this scheme process, and why won't 
it process others. As an example, FORTRAN is said to suffer 
needlessly, bound in the unaccustomed corsetry" of a syntax- 
oriented specification (2) . Gan it actually be represented 
in the metasyntactic and metasemantic languages proposed by 
Ingerman? Another example might be the production of a 
processor for a {probably} pathological language allowing 
free form input for a complex statistical program. 

(6} As stated before, the metasemantic language proposed 
by Ingerman leaves much to be desired, and much to the imagi¬ 
nation and ingenuity of the user. The question of A more 
general metasemantic language, or at least a more easily 
usable one would be a welcome addition to the technique. 

(7) An interesting project would be that of attempting 
to design a set of machine-independent macro-instructions for 
use by the unparsing processor. There has been some work 
done in the specification of semantics with respect to pro¬ 
ducing translators which are machine—independent. {16} A 

combination of this with Mr. Ingerman's metasyntactic language, 
and parsing and unparsing processors, might result in a very 
useful and general scheme which would approach the Universal 
Machine-Oriented Language hoped for many years ago. (14) 
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4• CONCLUSION 

A general discussion of syntax-oriented translation has 
been presented. Some of the problems inherent both in syn¬ 
tactic and semantic specification and in a processor to use 
sucn specifications have been noted. A brief description of 
syntax-controlled methods has been given, in order to show 
the more general nature of syntax—oriented techniques. 

Syntax—iented methods can be used quite effectively 
in the study of computer languages. Once a syntax-oriented 
processor has been developed, it may be used to describe 
several source languages. The metalanguages involved can 
be used not only as input specifications to the processor, 
but also as design languages. The processor and the meta¬ 
linguistic description of a source language may be used as 
an experimental compiler for the source language. This 
compiler can be easily tested, modified, and expanded, simply 
by changing the metalinguistic description. 

However, syntax-oriented methods have certain disad¬ 
vantages. A major problem is that of their inefficiency 
because of their generality. Another is that of providing 
source language diagnostics in the case of ungrammatical input. 

The methods developed by Ingerman have been discussed in 
some detail. His translator includes a' simple processor which 
interprets both syntactic and semantic metalanguages. This 
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processor works with the metalinguistic statements in 
essentially their original form. The processor makes 
use of an acceptability table to avoid tracing out 
inapplicable paths through the syntax tree. 

It is not clear what kinds of source languages can 
be described using a syntax-oriented translator. It is 
not clear how efficient {in any sense) such a scheme 
might be in a production environment. What is clear is 
that these questions and problems cannot be investigated 
without more experience in using such methods. 
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6. APPENDICES 
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APPEVniX ft.t 

SPECIFICATIONS FOR META n 
WRITTEN IN MFTA II. 


.SYNTAX PROGRAM., 

PROGRAM = '.SYNTAX* ID .OUTI'ClL'*) .nUTI'EXIT*) *.»* 
t ST '.END* .lUTCFNO'l., 

ST = ID .LABEL * ' =' FX l .OUK'R'J., 

EX 1 = EX? * ('/• .0UT(*8T'*I) FX2) .LABEL *1. f 
EX? = ( EX3 . OUT ( ' 8F' *1I/01JTPIJTI 

% (EX3 .DUTt 'iE' I/OUTPUTI .LABEL *1., 

EX3 - ID .OUT (*CLL' M / 

STRING .OUT ( 'TST' *) / * 

'.LETTER* .OUT t 'LET* ) / 

' .DIGIT* .DUTf 'DIG'I / 

1 . SPCHAR * .OUTCSPCM / 

'.QUOTE* .OUTCQU'I / 

'.EMPTY* .OUTI'SFT'I / 

*t■ FX1 '/ 

'S' .LABEL *L EXT .flUTt'BT' *1) .OUT(•SFT • 1 . , 
OUTPUT « I'.OUT' M* t OUTI / 

'.LABEL ' -OUT! *LB' ) OUTI / 

'.DELETE* .OUTCOEL'I ) .OUT I'OUT') . , 

OUTI =■ '“t 1 1* ,OUT< 1 GN1 ' ) / 

*OUT{ *GN2 ' ) / 

'*** .OUT{'Cl ') / 

STRING .OUTI*C L * *)., 

10 = .LETTER A (.0IGIT/.LETTER1 .OELFTE., 

STRING = .QUOTE (CHAR i CHARI .QUOTE .DELETE., 

CHAR = .LETTER/.DIGIT/. SPCHAR., 

.END 
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APPENDIX 6.2 

Description of the INGERMAN Program 


This program is a direct implementation of the general 
purpose syntax-oriented translator described in (1). In 
this description, knowledge of the technique is assumed. 
Only those portions of the technique which are directly 
concerned with the implementation will be mentioned. 

Section 6.2.1 describes the current implementation 
with respect to what parts have not been included. Section 
6.2.2 describes the character set used in the input of the 
metalinguistic rule set. Section 6.2.3 describes the input 
specifications. Section 6.2,4 describes the output of the 
processor. 

6.2.1 Details and Restrictions 


Input to the processor consists of two control cards 
and a set of metasyntactic and metasemantic rules, followed 
by source language cards. The rule input routine constructs 
both the complete acceptability table and the extra informa¬ 
tion about the elements of R(L) , as described in Chapter 3 
of (1) . It is planned to have the ordering algorithm 
included in the rule input routine, but at present it is not. 

Restrictions on the form of the input are: (a) metacom- 
ponents must be four characters or less; (b) base ob jL ct.s 
must be one or two characters, delimited b} quo 

a. nine metacomponents followed 

syntactic rule can have at most nin 
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by one metaresult; (d) a semantic rule can have at most 80 
characters. Details of the input characters used in the 
implementation are given in section 6.2,2. 

The complete parsing processor as described in Chapter 
4 of (1) is implemented. 

In Chapter 5 o± (1) several additional metasyntactic 
functions are described. Of these, only the right context 
MSF is implemented. 

The unparsing processor {which interprets the metasemantic 
language) described in Chapter 6 of (1) is fully implemented 
using the flow charts of Chapter 7. There are three meta- 
pragmatic functions (MPF's) mentioned in Chapter 6 which art- 
implemented: £l, *v2n, and v3D. Implementation of the syntax 

generating constructs is included. However, there is as yet 
no provision for including the generated rules in the 
original rule set and making another pass over the source 
input. 

6.2.2 Character Set 

In (1) a notation is used which does not corresponu to 
the PL/I character set. The following table givi„s 
original notation, the implementation form, and an exam P 1( 
use taken from Figure 6.2 of the book. 
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Qriginal 


Implementation 


boldface 


single character 
in quotes 


boldface 


one or more char¬ 
acters in quotes 


lower case 
<<right context>> 


one to four 
characters 

< 1 > 


{ } 


Description/Example 

Base object as meta¬ 
component in syntactic 
rules. Buie (1] 'A 1 L 

Base object(s) for 
output in semantic 
rules. 

Rule 1401 <'MPY 1 > 

Metacomponents in N(L] 
Rule 144] AO T UAE 

Right context MSF. 

Must be punched left 
adjusted in A(4) field. 

Delimiters for 
constructs 


[ ] 


( ) 


Delimiters for 
clauses 


small caps 


a , 8 , Y 


% 


one character 


? 




# 


Dummy variable 
Rule {373 <S> 

Interpretation of 
embedded construct. 

punctuation 

MPF 


6.2.3 Input Specifications 

There are three types of input to the processo 
control cards, rule cards, and source language cards. 

Control cards are punched according to tnc fo.lowi 


formats 
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Columns 


Description 

Card 1: 1-5 

NROW: 

t of rows of acceptability table 

6-10 

NCOL: 

# of columns of acceptability table 

11-15 

NSTK; 

length of stacks 

76-80 

NCDS: 

# of cards of source language input 


These numbers must be right adjusted within the field. They 
need not be exact; the estimate should be larger rather than 
smaller. Currently in use for a language of 116 rules are 
175, 80, 80, 10. 

Columns Description 

Card 2: 1-4 The name of the head of the language {left 

adjusted). 

80 0 for no intermediate output 

1 for intermediate output 

Rule cards are punched with the syntactic rule and the 
semantic rule on the same card. The last rule card must have 
the characters ENDb punched in columns 1-4. Rule cards are- 
read with a format of (10 (A(4)) , 40(A(1))) * The first 10 t. 
of 4 characters each contain the elements of the metasyntactic 
rule. Each element may be a base object, a name, oi the 1 
context MSF, denoted by the characters <1>. Each element must 
be left adjusted within the 4 -character fj.elu. * “ L 
semantic rule is punched in columns 41-80. Tnere may *■ a no 
embedded blanks except within quotes as base object 
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I£ a metasemantic rule is longer than 40 character,, it must 
have a non-blank character in column 80. It may be continued 
in columns 41-80 of the next card. Column, 1-40 of the con¬ 
tinuation card are ignored. Thus a metasemantic rule may be 
80 characters long. (The current implementation will print 
only 7 4 of these characters, however.) Metasemantic rules 
rezer to components of the corresponding metasyntactic rule. 
Such reference is made by numbering the elements from right 
to left, starting with zero for the metaresult. Base objects 
and the right context MSF are skipped in the numbering. 

In the present implementation the rules must be sorted 
in the following way: (a) all rules with the same left-most 
metacomponent must be physically together; (b) within groups 
of rules with the same left-most metacomponent, the rules 
must be sorted so that if any two rules have the first k 
metacomponents identical, any rule between them must also 
have those first k metacomponents. In addition, if two rules 
have the same left-most metacomponent, the longer rule must 
precede the shorter one. 

Source language cards are punched according to the 
specifications of the language under study. The processor 
will read them one at a time as needed, using format (80{A(1 >) > 

An example of an input deck appears in Appendix 
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6.2.4 Output 

Standard output consists of a listing of (a) the rules 
read in; (b) the arrays P, FLAG, LMMC, COLOFA, and A (which 
are explained in the PL/I program listing in Appendix 6.5} ? 

(c) each source language input card as it is read; and (d) 
the output generated by the unparsing processor. 

Optional intermediate output consists of all the above, 
and also (a) from the parsing processor, a printout of new 
subgoals as they are established, and indications of what 
rule is being processed, and what rule is being recovered 
from; (b) the list PARSE, with the rule represented by each 
element of PARSE; (c) from the unparsing processor, the 
contents of each stack each time the stacks are pushed down 
or popped up, the current character in the semantic rule in 
use, and the contents of the negative numbered rows of MAI Hi.*, 
(used for storage of dummy variables} . 

An example of standard output appears in Appendix 6.4. 
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APPP\ni x 

SAMPLE IN»UT 


Liiuiun 

1234567890123456789.. 


CARD COLUMNS 

4444444448555556655666646 77778 

.L234567890123466789012845.67873 


175 

80 80 

10 

A5 


0 

LP AE 

AS 

<1 1)(2) > 

10 EQ 

L P 

<-*• STORF 1 7( ?1> 

10 L 

10 

<{?) 1 n> 

10 P 


^'LOAO'SU 1)> 

■JAE AE 


<tl ,A f S-*'CHS')> 

AE UAE 

AE 

< (7 K t f AVAOV,Si’SUB')> 

AO T 

UAE 

<f 1M2)> 


F 

F 

r 

T 

P 


FS 

T 

MO 

AF 

F 


<(3im-**EXP'> 
<f l)> 

<f n> 

<(!)> 


ur 

0 Ul 

<{?M 1)> 

UT 

P 

<-'L0AD*3t(U> 

LPN 

AE RPN P 

< (2 ) > 

L 

in 

<t I >> 

0 

Ul 

<tn> 

• t' 

AO 

<A> 

»-1 

AO 

<S> 

i * i 

MO 

<'MPY* > 

V 

MO 

<*0IV*> 

’A * 

L 

<* A*> 

'B* 

L 

<'B’> 

* C* 

L 

<T.*> 

■ D ■ 

L 

<*D*> 

•E* 

L 

<‘F'> 

• F' 

L 

< • F * > 

*0* 

0 

<'0’> 

• 1* 

n 

< • 1 •> 

*8' 

0 

<*8'> 

*9' 

0 

< 1 9 * > 

• = i 

f 0 

<> 

' I* 

ES 

<> 

' (• 

LPN 

<> 

' )• 

RPN 

<> 

FNO 




CARD ^^^8333444444444458666648556 

11 HI 111 2345678901 234567930 

4567890123456789012345678901234 > 


AAA=BBR* (CCC+DDD*! EEE-FFF/t ABC I OFF ) 1 > 














74- 


AJPFyniy k.h 

SAMHF OUTPUT 


THE 

UFAD nF THF LANGLIA.*E IS: 

AS 

I 

SYNTACTIC 

sfmantt: 


PULE! n 

RIJLPfl) 


1 

LP 

AF 

AS 


<f1)[?)> 

2 

I 0 

EO 

L P 


<-** STORE ' TPI > 

3 

ID 

L 

ID 


<1 2)M 1 7 

4 

ID 

P 



<-.*LOATTm> 

5 

I.JAE 

A E 



< 11 ,A ,S-.«rHS • )> 

6 

A £ 

JAE 

AE 


<t ?)( ltA-» , A30 , ,S-' , SU8 , )> 

7 

AO 

T 

UAC 


<UH?t> 

8 

F 

ES 

P 

F 

<f 3H 11 -»• FXP' > 

7 

F 

r 



< m > 

10 

T 

MO 

F 

T 

<f 3 H 

It 

T 

AG 



<(1)7 

12 

P 

F 



<( 1 I> 

13 

UT 

D 

UI 


<I?H1 l> 

14 

UT 

P 



<-aoA3'im> 

15 

LPN 

AE 

RPN 

P 

<( 7)> 

1 6 

L 

i n 



<m> 

17 

D 

UI 



<m> 

18 

' 

AD 



<A> 

10 

i - • 

AO 



<S> 

20 

. 

MO 



< * MPY 1 > 

2L 

'/• 

MO 



<»DTV’> 

22 

• A* 

L 



< * A' > 

23 

• B • 

L 



<*B*> 

24 

' C* 

L 



<'C> 

25 

• D' 

L 



<»□•> 

26 

• E* 

L 



<*F«> 

27 

i ft 

l. 



<* F* > 

28 

* O' 

0 



< *n*> 

20 

. i» 

0 



<»l ■ > 

30 

t gt 

D 



<"?*> 

31 

. gt 

D 



< ' 0 ' > 

32 

* s * 

EQ 



<> 

33 

* 1 * 

ES 



<> 

34 

* {' 

LPN 



<> 

35 

' )' 

3PN 



<> 

36 

END 
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I 

P FLAG 

IMMC 

1 

IP 

0 

l 

7 

A E 

0 

6 

3 

AS 

0 

0 

4 

10 

0 

2 

5 

FG 

0 

0 

6 

L 

0 

16 

7 

P 

0 

12 

8 

UAE 

0 

5 

9 

A Cl 

0 

7 

10 

T 

0 

10 

tl 

F 

0 

B 

12 

ES 

0 

0 

13 

MO 

0 

0 

14 

UT 

0 

1 3 

15 

D 

0 

17 

16 

LPN 

0 

15 

17 

8 PN 

0 

0 

18 

+ 

l 

18 

19 

- 

1 

19 

20 

* 

1 

20 

21 

/ 

1 

21 

72 

A 

l 

22 

23 

B 

1 

23 

24 

C 

1 

24 

75 

0 

1 

25 

26 

F 

l 

26 

77 

F 

1 

27 

28 

0 

1 

28 

29 

1 

1 

29 

30 

8 

1 

30 

31 

9 

1 

31 

32 

s 

1 

32 

33 

1 

1 

33 

34 

( 

1 

34 

35 

) 

1 

35 

36 

AE 

0 

6 

37 

EG 

0 

0 

38 

L 

0 

16 

39 

UAF 

0 

5 

40 

T 

0 

10 

41 

E S 

0 

0 

42 

P 

0 

12 

43 

MO 

0 

0 

44 

F 

0 

8 

45 

0 

0 

17 

46 

AE 

0 

6 

47 

ft PN 

0 

0 


A 

mum 

)2345678901234667 

i onooooooooooooo" 
0000100000000^000 
0000000000000 ^ 00 ^ 

1111101lOOOOOOOOO 
oooooooooonoooooo 
i m louonoooooon 
0000101100000 noon 
00001OOOOOOOOOOO^ 
ooooiioooooooooon 

OOOOIOOIOOOOOOQOO 
0000101lOOOOOOOOO 
DOOOOf'OOOOOOOOOO' 1 

nooooooooooooooor 
00011011100000000 
ooouoin oooooooo 
ooou on ooorooooo 
ooooooonooooooooo 
ooo^ilooniooooooo 

OOOOUOOOIOOOOOOO 
00000000001000000 
ooooooooooioooocn 
imioiioooionooo 
11111011000100000 
iitiini ioooiooooo 
unioi ioooiooooo 
nuiouoooiooooo 
ml 1.011000100333 
noonoi i tooninono 
roouoi i loooi nooo 

OOGllOUlOOOtOOOO 

oootion tonoioooo 

ooooooonoooooioon 

OOOOOOOOOOOOOOIOO 

oooi i otiooooooni o 
coooooonoooooopoi 
looooooooonoooooo 

noooooonoooo ft ooo 

1111101lOOOOOOOOO 

oonoiooooooooooo-' 

OOOOllOPOOCOOOOOO 
OOOP1011ooooooonr 
OPO0101lOOOOOOOOO 
00O01OO lOOOOOnOOP 

ooooiooloneoooopp 

OOOI L011 lOOOOOOO' 1 
pom l 011 00000000" 
oooi i onoocoo^oo ' 1 


COL 

OF 

A 

2 

5 

1 

3 

14 

1? 

4 

6 

10 

8 

7 

15 

LI 

9 

13 

16 

17 

0 

0 

0 

0 

0 

n 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

9 

5 

14 

1? 

6 

8 

IS 

4 

u 

7 

13 

5 

17 










SDJRCF LANGUAGE INPUT 
4afl+C *D/El F 


7ft 


target language output 


L DAO P 

LOAD C 

LOAD 0 

mpy 

LOAD F 

L HAD F 

FXP 
DIV 
ADD 
STORF 


A 
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SOURCr language TNPUT 

AAA b BB r * * CCC+DDD+ tEEE- = FF/(ARC|OEF) M 


TARGET language output 


LOAD 

BRB 

LOAD 

CCC 

LOAD 

ODD 

LOAD 

EEE 

LOAD 

FFF 

LOAD 

ABC 

LOAD 

DEF 

EXP 


OTV 


SUB 


mpv 


ADD 


MPy 


STORE 

AAA 
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LI ST I MR OF PL/T PRnr.RAM 


/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

f* 

/♦ 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

l* 

(* 

/* 

/* 


* * * * *M***t*M*tt^ 


program to im^lfment the translator 

DEVELOPER By P. 7. INGERMAN 

*#***•##******, 

VARIABLES GLOBAL TO ALL ROUTINES 


P 

LMMC 

COLOF 

R 

A LABE 
FLAG 

A 

M ROW 

MCOL 

NUM_R 

PARSE 

LPARS 

DUMPS 

HEAD 

MATRI 

RULFS 

BADSW 


LIST OF ALL BASF OBJECTS AMO NAMES, PLUS AIL 
NON-LMMC* S. PARALLEI TD A. 

POINTER TO FIRST RULF WITH THIS ELMENT DF 
P AS THF LMMC, OR ZFftn. 

A - POINTER TO COLUMN OF A FOR THIS ELEMENT 
OF P, DR ZFtO. 

RULE MATRIX - ALL ELEMENTS ARE POINTFRS TO 
P ARRAY. BASF OBJECTS ARE < 0, NAMES > 0. 

L - POINTER TO ELEMENT OF P WHICH HFAOS THIS 
COLUMN OF A. 

EACH ELEMENT = 0 FOR NAME, 1 FOR BASE OBJECT 
FOR THIS ELEMENT (IF P. 

ACCEPTABILITY TABLE. 

TOTAL NUMBER OF ELEMENTS OF P fANO ALSO LMMC, 
COLOFA, AND NUMBER OF ROWS OF A). 

TOTAL MUMP Ft OF COLUMNS OF A CANO FLFMFNTS OF 
ALABFL). 

ULES - NUMBER OF RULFS READ IN. 

- LIST OF tULES USED IN PARSING. INPUT TO 
UNP AR SF_ P ART . 

E - POINTER TO LAST ELEMENT OF PARSE. 

W =0 FOR NO INTERMEDIATE PRINT-OUT, *1 FFR 
INTERMEDIATE PRINT-HUT. 

NAME OF HEAD OF LANGUAGE. 

X SEMANTIC RULE MATRIX. 

CHARACTER s ORM OF SYNTACTIC RULES. 

INITIALLY ZERO, SET TO 1 IF PARSING FAILS, 


*#*##*#**(1 * * * * 


******* 


•/ 
♦ / 
*/ 
• / 
*/ 
• / 
*/ 
•/ 
•/ 
*/ 
♦ / 
*/ 
*/ 
•/ 
♦ / 
*/ 
♦ / 
♦ / 
•/ 
• / 
*/ 
*/ 
*/ 

• t 

• f 

• f 

• / 
*/ 
*/ 
*/ 
*/ 
*Z 
*/ 
*/ 
*/ 
• / 
*/ 
*/ 
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/*********•*********, 

/* MAIN CONTROL ROUTINE 

/* */ 

/**#** + **♦** ********* t * #<t# , tt#/ 
MAIN.PRDGRAMS PRnCEDIUF OPTIONS (WN); 

/# * READ IN VARIOUS DIMENSIONS */ 

OFT EDIT! Nftnw * NCOL f NSTK f NCOS! I 3( FI •>)) ,X( AO) ,F< S) >; 
CALL PROCESS; 

PROCESS! PROCEDURE; 

DECLARE (P(NRDW), RULES!NGDW,101, HEAD! CHARACTER {4J ; 
DECLARE 11MMC (NRD W) r COL0FA (NROW) f R( MRDW ,-D: NCOL ), 
ALABFL tNCOL) T PAftSF(IO*NSTK> f MROW, wcoi, 

NUM_RIIL FSf LPARSE) REAL FIXED BINARY; 

DECLARE t FL AG(NRDVf) * A( NRnw.NCOL) * DIJMPSW, BADSW) 

BIT !L)J 

DECLARE FTND_IN_» ENTRY RETURNS (FlX r l BINARY); 
DECLARE MATRIX!-NROW;NROW» 50) CHARACTER (1); 
ft ♦/ 

CALL INPUT_PART; 

C ALL P: CALL P ARSE_PART ; 

IF BADSW THEN GO TCI CALLP; 

CALL UNPARSE_PART; 

GO TD CALLP; 
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/***** ************* *-**i** 9 i 9 

/* 

/* RULE INPUT RniJTINF 

/* 

/***********:fr*******o***** # * 

INPUT_P ART: PROCEDURE; 

DECLARE TBIT RT T (1), RIN(IO) CHARAC TFR (41: 

/* * INI TT AL I 7ATI ON 

p<*)=' •; 

lmmci*1=0; 

C OLflF A ( * )=0; 

FLAGt*)=• 0 * B; 

ri*,*>=o; 

ALABELt*) = 0 ; 

At*,* )=* 0 *B; 

matri x(*,*)=* •; 
m=o; 

N=o; 

GET EDIT tHFAD,DJMPSW) (A(4),X(75),R(1I); 

PUT PAGE FDIT I 'THE HFAD OF THE LANGUAGE IS ' ,HFAD) 

(At 28),A(4I) ! 

PUT SKIP (2)| 

L INF * 3; 

CALL HEAD 1; 

/* * READ RULES AND CONSTRUCT FIRST ORDER CHAINS, */ 

/* rig LOOP DN T FDR THE WHOLE SFT OF RULES. */ 


• / 
• / 
*/ 
* */ 


*/ 


I - 1! 

R EAD_A RULE: GFT EDIT t RI N, l MA TRI X 11 , J ) HO J«1 TO ADI) 
(1 Of A (4) ), 40 (At ID) ; 

IF MATRIXtI,40) ' 1 THEN GET EDIT I ( MATRI X ( I * J ) 

DO J=41 TO 80 )) I X t 40) ,40t At l)) ) ! 

IF LINE > 55 THTN CALL HEADl! 

PUT SKIP EDIT t I, RIN,t«ATR IXI I, J> DO J - l TO 3 
(F ( 3 ),X l 3) ,101 A( 4)), 34( A ( HI) I 

LINE = LTNF * If 
IF MATRIXU,35) -= ' 1 THI7N nfl * 

PUT SKI 5 EDIT (I MATRIX! I ,J) 
tX t 50) ,4M At 1 ) )): 

LINF = LINE t 1; 

END? 

RULES!!,*) = RlNt *>; c 

/* SMALL LOOP IN J FDR FACH RUIF. 

IF RINtl) = 'END ' THEN DO; 

NUM.RULES = 1-15 G0 TC1 P4RT - ’ 

END; 


[)0 J * 35,80) ) 


• / 


J = 1; 

.LOOP: TBI T= ' O'R; .. TLirw nn . 

IF SJBSTRtR IN! J )» 1 » 1) = '' t Jj N 

IF SUBSTRtRTN!J)*3,1>- 

lfn=i; else lfn = ; ; TB it=m*b; 

RIN(J) = SUBSTRtRIN!J).2»LEN). 

END; 
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*** RULE INPUT ROUTINP (CONT'DI *** 


/* * 


/* * 


IN. Pi 


/* * 

/* * 

/* * 


L POK FOR ANO RECODE M$F*S 

IF SJBSTRIR IN {J ), 1,1) = .<• Th(:n 00 , ' 

RU,-RJ = 5URSTR (R INI J) •?« l) t 
PI 11 - 2 ) - J- 1 j 

no < = J + l ro 10 ; RINtK-I) * RINIK); FnO; 

GO TO J_LnQ a ; 

END; 

HRnw * M; 

K = F IND_TN_P {RIV1 (J ), T8IT); 

PUT NEW M FTACDMPDNFNT IN P ARPAY IF NOT THTOP. tf 
IF K * 0 THEN DO; 

M-M+1S 

P(M)*RINIJ); 

FLAG(M)=TGIT; 

K = M; 

END; 

IF J=1 6 LMM CtK) =0 THEN LIMMC(K) = I; 

IF TBIT«»1'B THEM K=-K; 

R( I,J t«K; 

IF J< NCOL £ RINtJ + n-=* • THEN DO; 

J*J+1; GO T3 J_LOnP; 

END? 

THF END OF THIS RULF - FINISH IT UP * •/ 

R{ 1,0 ) = J; 

K = AGStK>; 

SET UP THF COLUMN OF A FDR THIS META-RESULT • */ 
IF COLflFA IK ) = 0 HEN DO; 

N = N+l; 

AL ABEL IN)=K; 

COLOFAIKI-N; 

fnd; 

I P= COL0F A(K ); eonu i uur rn m_r • •/ 

SET FIRST ORDER RULE CHAIN FRDM LMMt Tfl M P. 

IQ = ABSIRU. U); 

A (I Q, IP)='l'B; 

1 = 1 + 1 ; 

GO TO read_a_rule; 














/* * 
PART 


/* * 


/* * 


~e?- 


*** RULF IN>UT ROUTINE (CONT-I)) *** 


FNTER NON-LEFT M-C*S 
?: DO I = l TO NJM Rut FS; 
IF R( ItO) > 2 THEN f>0 J = 
IF R(I,J)>0 THEN 00; 
+ 1 ; 


INTO P AS NFW r.DHPCJNFNTS 
? TO R( j f OJ -I ; 


K = R fI,J ); 

PH) =p( K) ; 

FLAG!M)=FLAG(K); 

LMMCfM)=LNHC(K); 

COLOFA(M) = COLDFAt K J; 

R ( I, J )=H; 

AI M,COL OF A ! R(I,R(I* 0))) ) * *pR; 
END; 

ENO; 


*/ 


FND; 

FINISH UP THE EXTRA ROWS OF THF A MATRIX * */ 

DO J * l TO N; 

I P * ALABEl (J); 

no r = i to m; 

IF I-«= I P 6 AdtJl-'L'B THFN All,*) = A [ I, *1 | A U P, * 1 ; 
ENn; 


fnd; 

hrow = «; 

MCOL = n; 

intermedtatf print out * ♦/ 

L INE = 56! 

NN = t N/? ) + 3• 

DO 1=1 TO M; 

CALL HEA02; 

PUT SKIP EDITH ,PI T) * FLAG f [)• LMMC (D ,C3LTFAU I, 

I A ( 1 1 J ) OO J = 1 TO N) ) 

(F (5), X t 51 »A (4) ,BI 1) ,21 FI 5 )), 

X 15) ,100(0(11 M; 

FNO; 

RETURN; 
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*** PULP IM>UT ROUT INF (CflNT'D) **» 

/* * ROUTINE TO 5 RINT FIRST HEADINGS */ 

HEAD!: PROC ED1JRF ; 

IF LINE > 5*5 THFN DO; PUT PAGE; LIN«= * P; FND* 

PUT SKIP EDIT I 1 1 1 SYNTACTIC*» 1 SFMANTIC•| 

( XI 11 f M n .X t 4) ,A( <JJ ,x(31), A(8) J ; 

PUT SKIP EDIT ('RULE! t) S'RlllEHl •) 

( X (6)» At 7) ,xm ) ,A( 7 )>; 

PUT SKIP (2); 

L INE = LINE + 3; 

RETURN; 

END HEADl; 

/* * ROUTINE TO PRINT SECOND HEADINGS */ 


HE AO 2: PROCEDURE; 

LINE = LINE + l; 

IF LINE <= SS THEN RETURN; 

PUT PAGE; 

PUT SKIP EDIT ( 'COL* 1 » 'A 1 ) l X( 23)»A14) *XI NN) #A U >); 
PUT SKIP EDIT { *1 1 , ' P'» 'FLAG* f * LMMC* » 'OF 1 . 

IK/1 0 DO K = 10 TO N I ) 

(X(4), At 1 ),K (S),A(L),X(?),A(4) f XIlI,At4J,XI?)t 
At 2) ? X ( l3),70(Ffl)) ) ; 

PUT SKIP EDIT (* A 1 * (MODI K , ID J DO K=t TD Nil 
( X ( 2411 Alllf X( 5),80IF(1II); 

PUT skip; 

LINE = 5; 

return; 

end; 


END I NPUT_PART; 

/* * ROUTINE TO FIND ELEMENTS OF P 


F I ND_ I N_ P: PROCEDURF UTE«,TFST8ITI FIXED BINARY; 

DECLARE ITEM CHAR AC TER t *1 , TESTBIT BITU». 

?2 = testait then return tmi 


END; 

RETURN 10) ; 

END F IND_1N_P; 
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/*******************, 

/* 

/* PARSING PROCESSOR 

/* 

/*$****‘#*< t *4‘**#**# + #**, #t# 
PARSE_PARf: PROCEDURE; 

DECLARE ( Gil AL (VI STK J i INPUT{ NSTKl,niJTPUT( NSTKJ , 
NULL (NSTK ) « P X IT {4*NSTK J, CONST I4*NSTK), 

R EF( 4*NSTK )» 11 NK(2*NSTK1 ,RUL Ft A*NSTK M 
FIXED BINARY REAL; 

DECLARE (TEMP* TEMP?) REAL FIXED BINARY; 

DECLARE S(90*NCDS) CHARACTER!!); 

DFCLARF CTEMP CHARACTER (A) * IS REAL FIXED BINARY; 
DECLA RE NUU.RC BI TU) ; 


• */ 
*/ 
♦ / 
• / 

• •/ 


BADSW-•0* R; 

PUT PAGE FO ITl* SOURCE LANGUAGE INPUT’ ) I At 31)); 

PUT SKIP (2); 

CTFMP = *■; 

KNULL = FIND„IN_?(CTEMP, * 1 • B > ; 

/* FIND HEAD 0= LANGUAGE IN P - IHFAD IS POINTER */ 

IHFAD = FTND_IN J» ( HEAD,'CMR ); 

/* READ AN INPUT CARD */ 


IS = 1; 

CALL GET_S; 

/* FIND S(l) IN P - I IS POINTER 

I = FIND_IN_PISI1)*M'SH 
J=C0L0FA(IHEAD) ; 

/* SET FLAG TO l FOR RULE CHAIN FROM " TO HEAD 


NULLRC * '0*B; 

IF KNULL -v» 0 THEN NULLRC = ' I'B; 

* IS THERE A RULE CHAIN FROM 5(1) TO HFAP? 

IF -A(I,J) THEN GO TO TFST_NULL_1; 

* YFS - INITIALIZE */ 

NIT: TEMP = J; 

IG*INP»ID*INfIEtIR »IC»IRFtTL = l! 

RUl.Ft IR )*CONST( TC ) = 0; 

INPUT I INP),OUTPUT tIO) = U ctatfmfnT 

FXIT(IE) = 4; /* FLAG FOR END OF STATEMENT 

REF{rRF) t LINK(TL) ,NULL(IN) = 0: 

GO TO SET_GOAL; 


*/ 


*/ 


*/ 


• / 
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*** p/vr r n-; processor ( cont »n j *** 


/* IN ITIAL I7 ATI ON SECTION %f 

NUMOCR^l: 

f* PRESERVE GOAL, TN a LIT, nUTPUT, NULL •/ 

IOIG + 1; GOAL (IG1 = GOAL (IG-ll; 

INP - INP+l; TNPUTUNP} = INPUTtIN»-1 )• 

10 = IO+I; OUTPUT(TO) = OUTPUT! F0—11: 

IN = IN+l; NULL! IN) = NULL! IN-U ; 

S£T_GOAL: GOAL(TG) = TEMP; 

IF DJMPSW THEN ojT SKIP EDIT ( 1 GOAL IS % 

Pt ALABEL(GOAL!IG))), • LEVFL IS IG) 
f AIR) ,At4) f A( ll),F(5H ; 

/* IS THE INPUT CHARACTER THE LMMC OF SOME RLH C ? •/ 

I = F IND_IN_P 1S (I NPUT( INP H »• 1 'fl} i 
IF 1=0 THEN GO T) TEST_NULL_2; 

J = L MMC ( I) ; 

IF J = 0 THEN GO TO TEST„NULL_?; 

RULEt TR> = j; 

/* IS THERE A * ULE CHAIN FROM INPUT TO COAL? •/ 

IF tA t 1» GOAL { IG J) THEN GO TO TG ST_NULL_2 : 

/* YES»I NOE EOY / GO LOOK AT THIS t SUB-) GnAL */ 

NULL!IN) = 0; 

CALL UP.INPUT; 

GO TO NUMRER.4; 

/# IS THERE A LULE CHAIN FROM NULL TO HFAO? •/ 

TGST_NULL_ 1 - IF NULIRC THEN GO TO INlT; 

PUT SKIP ED IT (* NULI' ) (A ('4)) • 

GO TO EN02; „ , 

TEST_NULL_2: IF -.NULLRC THFN GO TO NUMBER.3 ♦ 

~ [ F NULL ( IN) -0 THEN GO TO NUMBER JJI 
H ?A: NULL!IN) = 1? 

K = LMMCtKNULL); 

GO TO NUMBER,*-; 
















*** PARSING PftQCFSSnR (CONT'D) 


*** 


/* 


PROCESSING SECTION 


*/ 


NUHRER_4: CONST!IC) = 2; 

/«■ TS R!R*C) IN NtL)? */ 

MA: IF OJMPSW THEN PUT SKIP FO IT ('PROCESS*. qmF(IR) 

CON ST (IC) * RULFSIRULEm ),*n 
( X! 10). A{ 7), 2! Ft 5)) ,XI*n ,10(At4m ; 

IF R! RULE ( IR) .CON ST t l CI J >0 THEN GO TO M 4B; 

/* NO - IT' S IN OIL i */ 

K = A0S (RtRULEUU, CONST! ICin*, 

/# IS R!R.C ) THE INPUT CHARACTER? +f 

IF $( INPUT! TNPl) -.= P {K) THFN GO TO NUMBER 3; 

/* YES */ 

CALL UP_INPUT; 

NUMBER_6: CONSTHC) = CONSTIIC) + l; 

GO TO /HA; 

/* R(R,C) I S IN NfLl - TS IT 4 META-RESULT? */ 

MB: IF CONSTHCJ < R(RULE!IR),0) THEN GO TO #4C; 

/* YES - TS THERE A RULE CHAIN FROM HFRF TO GOAL? */ 

K = RtRULEUR).CONST! TT J ) ; 

IF AIK, COAL UGH THFN GO TO MO; 

/* NO - ARE WF AT THF GOAL? •/ 

NUMBCR_5: IF Rt RULE {I RJ, CON ST! ICH * Al ABEL! GOALUG11 

THEN GO TO N UMBER_7; 

FLSF GO TO NUMBER_3; 

/* META—COM PON: NT - IS THFRE A RULE •/ 

/* CHAIN FROM HFRE TO GOAL? * / 

MC: K = RtRULEUR) .CONST! IC )) ; 

IF -.A (K.GOAL! IG)I THEN GO TO NHMBFR_3i 
/* YFS - GO A NEW SUB-GOAL. SD J 

/* PRESERVE STUFF AND GO RACK. 

IF = I F+l; EXIT! IF I = Si 

IR = IR + l; RULE! IR) = RULEHR-1); 

IC = IC + T; C0NSTUC1 = CONSTIIC - U! 

IRF a IRF+1; REFtIRF) * LINK(IL); 

TEMP * COLOFAIK); 


/* 

MO: 


TO NUM8FR_li 

Rill F CHAIN FRDM HERE TO C.nAL 




IE = IE+L: EXIT! IEI = 
IR = IR+l; RULE!IR) - 
IC = IC+1; CONST(IC) 
IRF = IRF + T ; REF! IRE) 
GQ TO NUMBER.*: 


LMMC (RIRULE! IR-1)»C0NST! IC ))>« 
* CONST(IC-l): 

= LINK!r L > * 
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*** PARSING PROCESSOR (CONT'O) *** 


/* 

RECOVERY SECTION 


f* 

ARE AIL CONSTITUENTS TO THF {.FFT OF THIS 

*/ 

/* 

ONE EQUAL TO THE CONSTITUENTS 

• / 

/* 

OF THE NEXT RULE? 

•/ 

NUMBER_ 3 : 

IF DUMPSW THEN PUT SKIP EDIT t 'RFCOVER FROM', 
RULFtIRI, CONSTUCU (X( 101 «A{ 121 ( 2 (F| 51 H 1 


no J =1 TO CON ST 110-1; 

JRPl = ABSIRIRULFt IRJ+l.J)); JR = AASI * (BtlU ( IR J, J11; 
IF JRP1 -■= JR THEN IF P(JRP1) P (JR > THEN GO Tn *3A; 
FNn; 

RULFI TR ) = RULE! I R J + 

TF R( RULF (TR) »CONST! IC1I = R( RtJLF 11R1-1 ,CONST ( IC1 ) 
THFN GO TO NUMRER_3; 

ELSE GO TO S 4A; 

#3At IF NULL(IN) -.=0 THEN GO TO «3R; 

ELSE IF -NUllRC THEN GO TO #39; 

GO TO ff2A; 

S3B: IF REF(IRF) -= LINK! ILI THEN 00; 

1 L = IL-l; 

GO TO H 3B; 


IRF » IRF-li 


IG-t ; 


END; 

EXITf TE) = EX IT(IF) - 3; 

NUMRFR_9: TEMP2 = EXITllElJ 

IF'djmPSW THEN PUT SKIP FOIT t , TFHP2=',TFMP2» 

IX(10) ,Af6 Ff SI IS 
IE = IE-1; IR = IR-1S IC = IC-I 
IF TEMP2 = 1 THEM GO TO BAD; 

IF TEMP? = 2 THEN HO; 

10 * 10-1; I NP = INP-l; ig * 

IN * IN-1; GO TO NUMRFR„3; 

FNO; 

IF TFMP2 * 3 THFN GO TO NUMRER_5; 

IF TEMP? = 4 THEN DO; 

PARSE (OUTPUT UOU * TEMP; GO TD ENOJ _ LL. 

END; 

IG = IG-1 ? IN * IN-1! 

/* LOSE OUTPUT T / _ . . 

10 = ID—1; OUTPUT! 10) = 0UT ^I ( !°* ]lur 

LHSF INPUT, UNLESS THERE'S * ynRE inPUT */ 

CONTEXT MSF, IN WHICH CASE JUST RfSTORE 

INP a INP-l; ,010111 FUR) ,-?)=CONST(lCn 1 

IF M (R(RULE(IR)t- 3)=1) G J.JJJXi*} • 

THEN IN 3 UT(I NP ) a INPUTUNP+1) • 

IL - IL+l; LINKtlLJ s TEMP; 

GO TO NUM8ER_6; 


/P 

/* 
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*** PARSING ORDCESSflR |C0NT'D> it, 


OUTPUT SECTION 


• / 


NUMB6R_7: TEMP = -OUT>UTUni; 

0 7AS PARSE (OUTPUT { 13) } = RULE<TR|; 

#78: OUTPUT (IOI = nuTPUT(IO) + 1 ; 

IF OUMPSW THEN PJT SKIP FDIT 1 'OUTPUT* , PULEURI, 
OUTPUT(10 ) -1 ) (X(10)»A(6)»P(F15))J; 

IF RE F ( IFF) LINKITL1 THEN DO: 

PARSE! OUTPUT (101) = LINKUU; 

IL = IL - l; GO TO #78; 

FND; 

IF EXITUE) 6 THEN GO TO NUMflER.P; 

IE = IE-1; IR = IR-l; IC = IC-l; T R F - I *>F-1; 

GO TO #7A; 
















*• * 
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*** PARSING PROCESSOR tCONT*f» 


/ + RETURN SECTION 

OAO: PUT SKIP FOIT ('3AO') (4(31); 

8AOSW = ' l' ft; 

GO Tn EN02; 


EN D_IT_ALL t 

END?: LPARSE = nUTPUT(in); 

IF I.PARSF - 1 THEN RETURN; 
IF -.OURPSW THEN RETURN; 


PUT PAGE; 

00 I = 1 TO LPARSF; 

K ■ PARSE! I] ; 

IF K< 0 THEN 00; 3 UT SKIP EDIT f PARSFI I))( F| 1ft )) j END; 
ELSE DO; PUT SKIP EDIT ( I t PARSF(II, 

IRUt. FSIK.J) OH J ~ 1 TO ID) t 
IM ATR T X ( K T J) 00 J - 1 TO AO) I 
( 2( F ( 5 )) i X( 5 i f 1 0( A( 4))«60( A( 1) I) i 


ENO; 


ENO; 

rfturn; 


/* PARSING utility subroutine 


*/ 


UP_TNPUT; PROCEDURE; 

INPUT(INP) = INPUT!INP) ♦ 1; 

IF IN PUT tINP J <= IS + 79 THFN RFTURN: 
IS * IS+80; 


GET_S ’ FNTRY; 

GET EDIT ((SfI) 00 I 
PUT SK IP EDIT USII) 
RETURN; 

END JP.INPUT; 


s IS TO TS + 79)) {801 MU) IS 
DO 1 = I S TO IS* 79)) tnoumnt 


ENO PARSE_PART; 











*** UNPARSr^G ’IDCESSOR t-ONTO) 




NJMBER_4A: INSI0F(PTO a 1 IN) s I OF ( PTR ) ♦ i 

NUMBER^ CALL SUBC; 

K = CT(PTR) + CHAR; 

CALL SUBC? 

IF CHAR THFM GO TO «0; 

OUTPUT = *0 '0; 

GO TO » 5A; 

#$: IF CHAR = THEM 01; 

IF P -•= 0 THEM GO TO MUMRFR 3; 
CALL SURF; 

#5A: CALL SUBC? 

NEGtPTR) = M EG IPTR) - 1; 
FXTRUNEGIPTfU f 1J = 2; 
FXTRUNEGIPTR),?} = LFV(PTR); 
FXTRltNEG(PTR) ,3) * CT(PTR); 

MATRIXIMEGt 0 TR),1) - CHAR; 

CALL DUMPM; 

GO Tn tn; 

END; 

THEM 
THEM OD; 

P = P-1; 

THEM P * 


0 : 


I F 


CHAR * • )' 

IF P = 0 
ELSE DO; 

IF CHAR = ' ( ' 

GO TO NUMSER_3; 

#6: T3 - NEG(PTR); 

IF S.JBG = 1 0* R THFM DO; 
NJM 3ER_3 t CALL SU3B! 

GO TO » 4; 

END; 

CALL PRESERVE; 

LEV(PTR) = EXTRUT3,?); 
ROW(PTR) = T3; 

COL ( PTR1 = l; 

CTIPTR) = FXTR1(T 3* 3)I 
GO TD #2; 


CALL SURF; GO TO 10; END 
GO TO MUM0FR.3; END; 

P + 1; 










*** UNPA'SMG PROCESSOR (CONT-OJ **♦ 

NU^BER.i: IN SI DE [ P TR } = 1; 

NO 1A: CALL SUBB; 

NqZlB: TF CHAR = ■<« THEN 00; 

INSIKIP™! = INSIDE! SO in Nn .l 

TF CHAR = THEN 00; 

DO I = C0L(3TR)*1 TO 80; 

IF MATRIXnOHlPTRM) * . THEN 5o Tn 

END; 

GO in #4; 

NO.lftl: INSIDEIPTRI = INSIDEtPTR) - 

IF INSIDFIPTR] * 0 THFN CO TO NUMBER 0; 
ELSF GO TO MO lAf 

ENO; 

N0_1C: IF CHAR = •?' THFN 00; 

CALL SUBC: 

T * T+l; 

TF T-«= INSID E(°TR ) THEN GO TO NO 1C; 

IF CHAR ■>= ' ( i THFN DO; 

CALL SJBH; GO TO NUMBER ?; 

HMD; 

IF OUTPUT THEN GO TO NIJMRER_4A; 

END ; 

IF 0 THEN DO; 

CT3= CHAR ; 

CHAR = *?'; 

N0_10: T * T- 1; 

CALL SURE; 

IF T-»= 0 THE\l GO TO NO_ID; 

CHAR = CT3; 

END ; 

CALL SUBE; 

NUMDFR_2: CALL SURA; 

GD TO ND_1S; 
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*** UWA9SI9C 9HOCFSSOR (C'TMT’nj 




/* UNPARSTMf, PROCESSOR SUBROUTINES 

SUBA: PROCEDURE; 

SAi: CALL SU8C; 

IF CHAR - *' 1 • THEN DO; 

CALL SURE; 

S A1 “3: CALL SUBC; 

IF CHAR = *' • • THEN DO; 

CALL SJBE; GO TO SAI; 

END; 

CALL SURE; 

GO TO SA15 ; 

END; 

IF CHAR = THEN GO TO SURB l; 

IF CHART’S!' THEN CD TO SUBfll; 

IF CHAR='->* THEN GO TO SUBBl; 

RFTURN; 

SUBF): ENTRY; 

SUBBl: CALL SURE; 

GO TO SAi; 

END SUBA; 

SUBC: PROCEDURE; 

COL(PTR) = COL (PTR) + 1 ; 

IF COL(PTR) > 80 THEN DO; 

PUT SKIP FDI T f'ODPS* .RDHIPTRM (AIA),F(5I»1 
GO TO ENO_UNPARSE; 

END; 

CHAR = MATR TK (RO/) (PTRJtCDl (PTR)} ; 

IF DUMPSW = ' 0* 9 THEN RETURN; 

PUT SKIP EDIT ('CHAR*', CHAR) (415),Ad)); 
RETURN; 

END SUBC; 
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*** UNPARSI,|(! “SOCfSSnR (CONT'OI ... 


I 


<jUBD: PROCEDURE; 

SOI: T 7 = FXTR] (NFG f PTR ) ,i) ; 

MATRIX(NEG[PTR),T2) = CTF MP' 
EXTR1(NEGI PTR )» 1) = r?*l- ’ 

CAUL DIJMPM; 

RETURN; 


SUOE: ENTRY; 

IF IS M 0 THEN >0; IMP * IN P+1; 

IF I SW = 1 THEN NAME 1( INAHF) * 

SURSTRt NAMEK IN A HE 1 »l»I NP-l) | I CH Aft t 
IF ISM = 2 THEN NAMF2I1 NAME I = 

SUBSTRfNAME2IINANE),1 .INP-1 ) I JCHAP- 
IF ISW = 3 THEN TNAMF* * 

SUBSTRt TNAMEt 1,1 NP-l)||CHAR s 
RFTURN; 

END; 


IF -.OUTPUT THEN 00; CTFMP=CHAR; 2D TO SOI; EN0‘ 
IF CHAR = • ■ ■ * THEN RETURN; 

CALL OUTRTNtCHAR); 

RETURN; 

END SUBD; 


SURF: PROCEDURE; 
CTFMP = »>*; 
CALL SUBD; 
REtURN; 

END SURF; 


SUBG: PROCEDURE BIT!1) ; 

SGU IF T3 * 0 THEN RE TURN l ' 0« B) ; 

IF CHAR = MATRIX! T3,11 fl LEVfPTR) >FXTRUT3,2) 
THFN RETUR N f ' 1 ’ R ); 

T 3 = T 3 + 1 ; 

GO TO SGI; 

END SUBG; 
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*** UNPARSING PROCESSOR 


fCONT'o; mi 


SURHI 


SUBH1 


PROCEDURE? 


DECLARE BLAH CHAR ACTER(Q) ■ 

?ALL U SJRci '' 9 CHM * crE,u '' [N 'T 1 UI .n«R., 

I F CHAR * ■ )' TH5N Ofl; 

LARFL(PTR) S L40FLfPTR> + l • 

RL AH = L ABE. (OTR ); 

: CHAR = * *'•; 

CALL SURF; 

on 1 = 1 n 4 ; 

CHAR = SUBSTR {TLABi 1*1); 

CALL SJBE; 


END; 


IF 


IF 


SUBHEND: 


IF 


GO TO SUBHEND; 

END; 

CHAR - 1 V THEN DO; 

CALL SUBC; J J J = L ABF Li PTR J-CHA R; 
BLAH = JJJ; GO TO SUBH1; 

END; 

CHAR = *0’ THEN DO; 

T3 = NEGtPTR ) ; 

CALL SUOC; I Dl)M = SUBG; 

CHAR = *»ii- CALL SURF; 

BLAH = ABS (T 3) ; 

DO I = l TO 4* 

CHAR = SUBSTR (BLAH,1 + 5,1 ] ; 

IF CHAR -.= ■ « THEN CALL SURE; 

FNO; 

CHAR = ' " CALL SURE; 

RETURN ; 

END; 

CHAR = '4* THEM DO; CALL SURC; 

IF CHAR = '1 * THEN 00; 

I SW = 1 ; TNARF = INANE*l; 

INP * 0; RETURN; 

END; 

IF CHAR = '? ' THEN DO; 

rsw = ?; tnp = o; return; 
fnd; 

IF CHAR = *R' THFN DO; 

CHAR = •>'; CALL SUBE; 

I SW = 0; RETURN ; 

END; 

END; 
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*** UNPARSH& PRnCFSSOR 


tCONT'ni tM 


I F 


CHAR 

IF 


i n; rv 

*i * 


CHAR = 

ISW = i; 

INP = ■); 

END; 

IF CHAR - '?i 
DO I * l 
IF TNA'lE 
CHAR = 

IF CiAR s 
CALL SUBE; 
END; 
RETURN; 

END; 

RETURN; 


liu; CALL 
THFN DO; 
TNA«E = i 
RFTURM; 


5 URC; 


0 ; 


THFN DO; Isw 
TO FNAME; 

* N4 ME1(I| THEN do j 
SUBSTR(NAME?(I ), J, 1) ; 

t >* then rfturn; 


End; 
END; 
RETURN; 
END SURH; 


to ?o: 







- 97 - 


*** **“ S " E ’MMSSW .:ont.5| ... 


t* UMP ARSING UT ILITY S(JR R.nyTj Nf S 


pftFSFRVE: PROCFDURF; 


PTR = PTR + 1 ; 

INSIDF(PTR) = IKS ngt PTR-1) • 
rOw(PTR) * Rnw(PTR-n ; 

COH PTR) = Cni(PTR-l); 

LEVtPTR) = LEV(PTR-l); 

CT(PTR) = CT(PTR-i); 

NFG(PTR) = NEG(PTR-1>; 

LABEL (PTR) = LABEL!PTR - ])• 

IF DUMPSW = '0 1 R THEN RFTURN; 

°UT SKIP EPIT(PTRfKtlNSlDEIPTR) t RDWI PTR) , 
LFV (PTR) , CT( PTR ) ,NEG(PTR ),L4BEL( PTR) 
(9 I F (1 0 ) ) ); 

return; 

END PRESERVE; 


CDL(PTR), 

) 


• / 


RESTORE: PROCEDURE; 

PTR = PTR-l; 

IF DUMPSW = * O' B THEN RETURN; 

PUT SKIP EDIT (PTt »K f T NS IDE ( PT R), ROW (PTR) , COL I PTR) , 
LEV f PTR) ,CTI PTR) , NEG( PTR ), LABEL< PTR)) 
fOfFflOJ)); 

RFtuRN; 

END RESTORF; 
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UNPARSIMG PROCESSOR ICONT-O) 


flUTRTM' P ROC EDI JR F (CH4 R I ; 

DECLARE CHAR CHAR AC TEP( 1 ) , jpfR 
/* -.IS BETA, ?! IS GAMNA, f. is 
IF CHAR * THEN 

TF rLflC <= l TAB THEN OR; 
ILOC = I TAB; RETURN; 
END; 


inttial 

alpha 


FLSF DO; IP T R - I TAR; 00 Tfl 0UT2 - 

PMH * 


I0| ; 


OUT 1 
OUT? 


IF CHAR = •*’ THEN 03; 

IPTR = IL0C/IT4B; HOC = (1 + IPTft)*! TAB; 
IPTR = AMT4B; GO TO 0UT1; 

END; 

IF CHAR = «£* THEN GO TO OUT?; 

ILOC = nnc+ii 
LINE! ILOC) * CHAR; 

: IF ILOC < 120 THEN RETURN; 

: PUT SKIP EDIT [LINE) C120(MIU); 

L INF = * • ; 

ILOC * IPTR; 

return; 

END 3UTRTN; 


*/ 


DUMPM: PROCFOURF! 

IF' OUMPSW * ' 0 1 8 THEN RETURN; 

PUT SKIP ED IT (N EG (PTR ) , [ F XTR1 f NEG [PTR), J) 
DO J = 1 TO 8), (MATRIX!NEG(PTR) f J) 
no J = 1 TO EXTRMNEGl PTR ) f 11)) 
f X C 40) ,4{F(5 n,40(A< 1 ) )) ; 

RETURN; 

END; 

END_UNPAR$F: IF ILOC > 0 THEN CALL DUTRTNI 1 E') ; 
RETURN; 

END JNP ARSE .PART; 

END PROCESS; 

END HAIN.PROGRAH; 
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